Audiounterstützung von Hörgeräten über Bluetooth LE

Hörgeräte können die Barrierefreiheit auf Ihrem Pixel Android-Mobilgeräte mit verbindungsorientiertem L2CAP über Bluetooth Low Energy (BLE) zu empfangen. Bei der CoC wird ein elastisches aus mehreren Audiopaketen gepuffert, um einen gleichmäßigen Audiofluss aufrechtzuerhalten, im Fall von Paketverlusten. Dieser Puffer bietet die Audioqualität für Hörgeräte zulasten der Latenz.

Das Design von CoC bezieht sich auf die Bluetooth Hauptspezifikation Version 5 (BT) Zur Einhaltung der Kernspezifikationen werden alle Multibyte auf dieser Seite als Little-Endian gelesen werden.

Terminologie

• Zentral: das Android-Gerät, das nach Werbung über Bluetooth.
• Peripheriegerät: das Hörgerät, das Advertising-Pakete über Bluetooth.

Netzwerktopologie und Systemarchitektur

Bei Verwendung von CoC für Hörgeräte geht die Netzwerktopologie von einem zentral und zwei Peripheriegeräte, eines links und eines rechts, wie in Abbildung 1: Das Bluetooth-Audiosystem schaut links auf Peripheriegeräte als einzelne Audiosenke vereint. Wenn ein Peripheriegerät fehlt, aufgrund einer Mono-Anpassung oder eines Verbindungsverlusts, die zentrale Komponente den linken und rechten Audiokanal vermischt und die Audiodaten mit dem verbleibenden Peripheriegerät. Wenn die Verbindung zu beiden Peripheriegeräten betrachtet, berücksichtigt der Central die Verbindung zur Audiosenke. verloren. In diesen Fällen leitet die Zentrale die Audiodaten an einen anderen Ausgang weiter.

Abbildung 1: Topologie zum Koppeln von Hörgeräten mit Android-Mobilgeräte mit CoC über BLE

Wenn die Zentrale keine Audiodaten an das Peripheriegerät streamt und BLE-Verbindung aufrechterhalten, sollte die Zentrale nicht getrennt werden Peripheriegerät. Die Aufrechterhaltung der Verbindung ermöglicht die Datenkommunikation, mit dem GATT-Server auf dem Peripheriegerät.

Hinweis: Es gibt keinen Audio-Backlink zwischen dem zentralen und die Peripheriegeräte. Während eines Telefonats sind die zentralen Mikrofone für die Spracheingabe verwendet wird.

Beim Koppeln und Verbinden von Hörgeräten muss die Zentrale:

• Behalten Sie den Überblick über die neueren gekoppelten Peripheriegeräte.
• Angenommen, die Peripheriegeräte werden verwendet, wenn eine gültige Kopplung vorhanden ist. Die wird versucht, eine Verbindung zu den gekoppelten wenn die Verbindung unterbrochen wird.
• Angenommen, die Peripheriegeräte werden nicht mehr verwendet, wenn eine Kopplung gelöscht wird.

Im obigen Beispiel bezieht sich Koppeln auf die Aktion Registrierung eines Hörgeräts mit einer bestimmten UUID und links/rechts im Betriebssystem und nicht bei der Bluetooth-Kopplung.

Systemanforderungen

Für die korrekte Implementierung von CoC und eine gute Nutzererfahrung ist das Bluetooth-Symbol Systeme in den zentralen und Peripheriegeräten müssen:

• einen konformen Controller mit BT 4.2 oder höher implementieren. LE Secure Connections ist sehr empfehlenswert.
• mindestens zwei gleichzeitige LE-Links mit Parametern wie beschrieben im Abschnitt Audiopaket Format und Timing.
• Peripheriegerät muss mindestens 1 LE-Link mit den Parametern unterstützen beschrieben im Abschnitt Audiopaket Format und Timing.
• haben eine LE-Guthaben-basierte Datenflusssteuerung [BT Vol 3, Part A, Sec 10.1]. Geräte müssen eine MTU- und MPS-Größe von mindestens 167 Byte auf und bis zu 8 Pakete zwischenspeichern können.
• haben eine LE-Datenlängenerweiterung [BT Vol 6, Part B, Sec 5.1.9] mit eine Nutzlast von mindestens 167 Byte.
• das zentrale Gerät den Befehl „HCI LE Connection Update“ unterstützen soll Außerdem müssen die maximum_CE_Length und die minimum_CE_Length-Parameter.
• den Datendurchsatz für zwei LE CoC-Verbindungen zu zwei verschiedene Peripheriegeräte mit Verbindungsintervallen und Nutzlasten, Größen im Audiopaket Format und Timing.
• legen Sie für das Peripheriegerät Folgendes fest: MaxRxOctets und MaxRxTime-Parameter in LL_LENGTH_REQ oder LL_LENGTH_RSP Frames als die kleinsten erforderlichen Werte an, die für diese Spezifikationen erforderlich sind. So kann die zentrale seinen Zeitplan beim Berechnen der Zeit optimieren um einen Frame zu erhalten.

Es wird dringend empfohlen, dass das zentrale und das Peripheriegerät 2 MB PHY als die in der BT 5.0-Spezifikation angegeben sind. Die Mitte muss Audio-Links der mindestens 64 kbit/s auf 1 Mio. und 2 Mio. PHYs. Der BLE-Langstrecken-PHY darf nicht verwendet werden.

CoC verwendet die standardmäßigen Bluetooth-Mechanismen für die Verschlüsselung der Verbindungsebene und Frequenzsprung.

ASHA GATT-Dienste

Ein Peripheriegerät muss Audiostreaming für Hörgeräte implementieren (ASHA) des unten beschriebenen GATT-Serverdienstes. Das Peripheriegerät Diesen Dienst im allgemeinen Modus "Sichtbar" anbieten, damit das Audiosenke erkennen. Alle LE Audio-Streamingvorgänge ist eine Verschlüsselung erforderlich. Das BLE-Audio-Streaming besteht aus dem die folgenden Merkmale:

Charakteristiken	Properties	Beschreibung
ReadOnlyProperties	Gelesen	Siehe ReadOnlyProperties.
Audio-Kontrollpunkt	Ohne Antwort schreiben und schreiben	Kontrollpunkt für Audiostream. Weitere Informationen finden Sie unter AudioControlPoint aus.
Audiostatuspunkt	Lesen/Benachrichtigen	Statusberichtsfeld für den Audiokontrollpunkt. Weitere Informationen finden Sie unter AudioStatusPoint enthalten ist.
Lautstärke	Ohne Antwort schreiben	Byte zwischen -128 und 0, der den Grad der Attenuierung angibt, auf den des gestreamten Audiosignals zwischen -48 dB und 0 dB. Einstellung -128 als vollständig stummgeschaltet interpretiert werden, d. h. als die niedrigste nicht stummgeschaltete Lautstärke. liegt bei -127, was einer Dämpfung von -47,625 dB entspricht. Bei Einstellung 0 muss ein von Rail-to-Rail gestreamter Sinuston einen Eingang von 100 dBSPL darstellen. am Hörgerät entspricht. Die Zentrale muss Nennwert Vollbild und verwenden Sie diese Variable, um die gewünschte Peripheriegerät.
LE_PSM_OUT	Gelesen	PSM zum Verbinden des Audiokanals. Auswahl aus der Dynamic Range [BT Vol 3, Part A, Sec 4.22]

Die dem Dienst zugewiesenen UUIDs und Eigenschaften:

Dienst-UUID: {0xFDF0}

Charakteristiken	UUID
ReadOnlyProperties	{6333651e-c481-4a3e-9169-7c902aad37bb}
Audio-Kontrollpunkt	{f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
Audiostatus	{38663f1a-e711-4cac-b641-326b56404837}
Lautstärke	{00e4ca9e-ab14-41e4-8823-f9e70c7e91df}
LE_PSM_OUT	{2d410339-82b6-42aa-b34e-e2e01df8cc1a}

Zusätzlich zum ASHA GATT-Dienst muss das Peripheriegerät auch den Geräteinformationsdienst zu implementieren, damit die Zentrale die Hersteller- und Gerätenamen des Peripheriegeräts.

ReadOnlyProperties

ReadOnlyProperties haben die folgenden Werte:

Byte	Beschreibung
0	Version – muss 0x01 sein
1	Siehe DeviceCapabilities.
2-9	Siehe HiSyncId.
10	Siehe FeatureMap.
11-12	RenderDelay. Dies ist die Zeit in Millisekunden ab dem Zeitpunkt, an dem Peripheriegerät empfängt einen Audioframe, bis es gerendert wird. die Ausgabe. Diese Bytes können dazu verwendet werden, mit dem Audio synchronisieren.
13-14	Reserviert für zukünftige Verwendungen. Auf Nullen initialisieren
15-16	Unterstützte Codec-IDs. Dies ist eine Bitmaske der unterstützten Codec-IDs. Eine 1 an einer Bitposition entspricht einer Codec unterstützt. Beispiel: 0x0002 gibt an, dass G.722 bei 16 kHz wird unterstützt. Alle anderen Bits müssen auf 0 gesetzt werden.

Gerätefunktionen

Bit	Beschreibung
0	Geräteseite (0: links, 1: rechts)
1	Gibt an, ob das Gerät eigenständig ist und Monodaten empfängt Gerät ist Teil einer Gruppe (0: monaural, 1: binaural)
2	Gerät unterstützt CSIS (0: nicht unterstützt, 1: unterstützt)
3-7	Reserviert (auf 0 gesetzt)

HiSyncID

Dieses Feld muss für alle binauralen Geräte eindeutig sein, für das linke und rechte Set.

Byte	Beschreibung
0-1	ID des Herstellers. Es handelt sich um die Unternehmen IDs, die von BTSIG zugewiesen werden.
2-7	Eindeutige ID, mit der das Hörgerät identifiziert wird. Diese ID muss festgelegt werden am linken und rechten Peripheriegerät.

Funktionsübersicht

Bit	Beschreibung
0	LE CoC-Audioausgabestreaming wird unterstützt (Ja/Nein).
1-7	Reserviert (auf 0 gesetzt).

Codec-IDs

Wenn das Bit gesetzt ist, dann ist dieser Codec support.

ID / Bit-Nummer	Codec und Abtastrate	Erforderliche Bitrate	Frame Time	Obligatorisch auf zentralen (C) oder Peripheriegeräten (P)
0	Reserviert	Reserviert	Reserviert	Reserviert
1	G.722 bei 16 kHz	64 kbit/s	Variable	C und P
2–15 sind reserviert. 0 ist ebenfalls reserviert.

Audio-Kontrollpunkt

Dieser Kontrollpunkt kann nicht verwendet werden, wenn LE CoC geschlossen ist. Weitere Informationen finden Sie unter Start- und Stoppen eines Audiostreams finden Sie weitere Informationen.

Opcode-Code	Argumente	Untergeordnetes GATT-Verfahren	Beschreibung
1 «Start»	uint8_t codec uint8_t audiotype int8_t volume int8_t otherstate	Schreiben Sie mit Antwort und erwarten Sie eine zusätzliche Statusbenachrichtigung über AudioStatusPoint-Eigenschaft.	Weist das Peripheriegerät an, den Codec zurückzusetzen und den Wiedergabe von Frame 0. Das Codec-Feld gibt die zu verwendende Codec-ID an. für diese Wiedergabe. Beispiel: Das Codec-Feld hat den Wert „1“. für G.722 bei 16.000 Hz. Das Bitfeld für den Audiotyp gibt die vorhandenen Audiotypen an. im Stream: 0 - Unbekannt 1: Klingelton 2 – Telefonanruf 3: Medien Das Feld otherstate gibt an, ob die andere Seite des binauralen Geräte verbunden sind. Der Feldwert lautet „1“, wenn das andere Peripheriegerät verbunden ist. Andernfalls ist der Wert 0. Das Peripheriegerät darf keine Verbindungsaktualisierungen vor einer «Stop»-Opcode wurde empfangen.
2 «Stop»	Keine	Schreiben Sie mit Antwort und erwarten Sie eine zusätzliche Statusbenachrichtigung über AudioStatusPoint-Eigenschaft.	Weist das Peripheriegerät an, das Audio-Rendering zu beenden. Eine neue Audiodatei Einrichtungssequenz sollte nach dieser Haltestelle eingeleitet werden, um die Audiospur erneut zu rendern.
3 «Status»	uint8_t connected	Ohne Antwort schreiben	Informiert das verbundene Peripheriegerät, dass ein Statusupdate auf dem Peripheriegeräte. Das Feld „Connected“ gibt den Typ des Updates an: 0: Anderes Peripheriegerät getrennt 1 – Anderes Peripheriegerät angeschlossen 2 – Ein LE-Verbindungsparameter wurde aktualisiert über jede Verbindung

Audiostatuspunkt

Statusberichtsfeld für den Audiokontrollpunkt

Opcodes	Beschreibung
0	Status Ok
-1	Unbekannter Befehl
-2	Unzulässige Parameter

Werbung für den ASHA GATT-Dienst

Die Dienst-UUID muss in der Advertising-Pakets. In der Anzeige oder im Scan Antwortframe erhalten, müssen die Peripheriegeräte Dienstdaten haben:

Byte-Offset	Name	Beschreibung
0	Anzeigenlänge	>= 0 x 09
1	Anzeigenart	0x16 (Dienstdaten – 16-Bit-UUID)
2–3	Dienst-UUID	0xFDF0 (Little-Endian) Hinweis:Dies ist eine temporäre ID.
4	Protokollversion	0x01
5	Funktion	0: linke (0) oder rechte Seite (1) 1: ein (0) oder zwei (1) Geräte 2: Gerät unterstützt CSIS (<0: nicht unterstützt, 1: unterstützt) 3-7 – reserviert. Diese Bits müssen null sein.
6-9	Abgeschnittener HiSyncID	Die vier höchstwertigen Bytes der HiSyncId zu verwenden. Diese Bytes sollten der zufälligste Teil der ID sein.

Die Peripheriegeräte müssen den vollständigen lokalen Namen haben Datentyp, der den Namen des Hörgeräts angibt. Dieser Name wird werden auf der Benutzeroberfläche des Mobilgeräts verwendet, das richtige Gerät finden. Der Name darf nicht den linken oder rechten da diese Informationen in den DeviceCapabilities.

Wenn die Peripheriegeräte den Namen und die ASHA-Dienstdatentypen in derselben (ADV oder SCAN RESP), sind die beiden Datentypen ("Complete Local Name" und „Dienstdaten für ASHA-Dienst“) erscheinen, im selben Frame. So kann der Scanner des Mobilgeräts beide Daten abrufen, im gleichen Scanergebnis.

Beim ersten Koppeln müssen die Peripheriegeräte so schnell wie möglich zu werben, damit das Mobilgerät Peripheriegeräte zu entdecken und eine Bindung zu ihnen aufzubauen.

Linke und rechte Peripheriegeräte synchronisieren

Zur Verwendung von Bluetooth auf Android-Mobilgeräten, Peripheriegeräten sind dafür verantwortlich, dass sie synchronisiert werden. Die Wiedergabe müssen die auf der linken und rechten Seite enthaltenen Peripheriegeräte synchronisiert werden. . Beide Peripheriegeräte müssen Audiobeispiele vom Quelle gleichzeitig.

Peripheriegeräte können ihre Zeit mithilfe einer Sequenz synchronisieren. Zahl, die jedem Paket der Audionutzlast vorangestellt ist. Die zentrale sorgt dafür, dass Audiopakete, die im selben Zeit auf jedem Peripheriegerät dieselbe Sequenznummer haben. Die Sequenz wird nach jedem Audiopaket um 1 erhöht. Jede Sequenz Nummer ist 8 Bit lang, sodass sich die Sequenznummern nach 256 wiederholen Audiopakete. Da die Größe und Abtastrate jedes Audiopakets können die beiden Peripheriegeräte den relativen Wert die Spieldauer. Weitere Informationen zum Audiopaket findest du unter Audiopaketformat und

Die Zentrale unterstützt die binauralen Geräte durch die Bereitstellung von Triggern bei der Synchronisierung erforderlich sind. Diese Trigger informieren jedes Peripheriegerät über den Status seiner gekoppelten Peripheriegeräten immer dann, wenn ein Vorgang ausgeführt wird, der kann sich auf die Synchronisierung auswirken. Die Trigger sind:

• Im Rahmen des Befehls «Start» von AudioControlPoint den aktuellen Verbindungsstatus der anderen Seite des binauralen Geräte bereitgestellt werden.
• Wann immer eine Verbindung hergestellt, unterbrochen oder Aktualisierung der Verbindungsparameter auf einem Peripheriegerät, wird der Befehl «Status» von AudioControlPoint an die andere Seite der binauralen Geräte.

Format und Timing des Audiopakets

Wenn Audioframes (Sampleblöcke) in Pakete gepackt werden, Das Instrument leitet das Timing von den Link-Layer-Timing-Anchors ab. Bis die Implementierung zu vereinfachen:

• Ein Audioframe sollte immer mit dem zeitlichen Verbindungsintervall übereinstimmen. Wenn das Verbindungsintervall z. B. 20 ms beträgt und die Abtastrate 16 kHz hat, muss der Audioframe 320 Samples enthalten.
• Abtastraten sind im System auf ein Vielfaches von 8 kHz beschränkt, immer eine ganzzahlige Anzahl von Stichproben in einem Frame haben, die Frame Time oder das Verbindungsintervall.
• Ein Sequenzbyte muss Audioframes voranstellen. Das Sequenzbyte wird mit Wrap-around gezählt und das Peripheriegerät kann nicht übereinstimmende Puffer oder Unterlauf erkennen.
• Ein Audioframe muss immer in ein einzelnes LE-Paket passen. Das Audio als separates L2CAP-Paket gesendet. Die Größe des LE LL PDU:
  Audionutzlastgröße + 1 (Sequenzzähler) + 6 (4 für L2CAP-Header, 2 für SDU)
• Ein Verbindungsereignis sollte immer groß genug sein, um zwei Audioinhalte aufzunehmen Pakete und zwei leere Pakete für eine Bestätigung, um Bandbreite für erneut übertragen werden. Beachten Sie, dass das Audiopaket durch den Bluetooth-Controller der Zentrale. Das Peripheriegerät muss mehr als zwei fragmentierte Audiopakete pro Verbindungsereignis.

Um der Zentrale etwas Flexibilität zu geben, ist die Länge des G.722-Pakets nicht angegeben ist. Die Länge des G.722-Pakets kann sich je nach Verbindung ändern das die Mitte festlegt.

Das G.722-Ausgabeoktettformat verweist auf die Rec.- ITU-T G.722 (9/2012) Abschnitt 1.4.4 „Multiplexer“

Für alle Codecs, die von einem Peripheriegerät unterstützt werden, muss das Peripheriegerät unterstützen die folgenden Verbindungsparameter. Diese Liste ist nicht vollständig von Konfigurationen, die die Zentrale implementieren kann.

Codec	Bitrate	Verbindungsintervall	CE-Länge (1 Mio./2 Mio. PHY)	Größe der Audionutzlast
G.722 bei 16 kHz	64 kbit/s	20 ms	5000/3750 uns	160 Byte

Audiostream starten und beenden

Hinweis:Dieser Abschnitt basiert auf Simulationen mit einem Puffertiefe des Audioframes von 8. Diese Tiefe reicht aus, um zu verhindern, Unterlauf auf dem Peripheriegerät in den meisten Paketverlustszenarien. Damit ist die Netzwerkverzögerung im System das Achtfache der Verbindung Intervall. Um Verzögerungen möglichst gering zu halten, ist ein kurzes Verbindungsintervall bevorzugt werden.

Bevor ein Audiostream gestartet wird, fragt der zentrale Geräte die Peripheriegeräte ab und es wird ein Codec für einen gemeinsamen Nenner festgelegt. Stream und geht dann wie folgt vor:

1. PSM und optional RenderDelay wird gelesen. Diese Werte im Cache gespeichert werden kann.
2. CoC L2CAP-Kanal ist geöffnet – das Peripheriegerät gewährt 8 Credits anfänglich.
3. Ein Verbindungsupdate wird ausgegeben, um den Link zu den Parametern zu ändern die für den ausgewählten Codec erforderlich sind. Die Zentrale kann diese Verbindungsaktualisierung vornehmen. vor der CoC-Verbindung aus dem vorherigen Schritt.
4. Sowohl der zentrale Host als auch der Host für die Peripheriegeräte warten auf die Aktualisierung abgeschlossen wird.
5. Starte den Audio-Encoder neu und setze die Anzahl der Paketsequenzen auf 0 zurück. Ein «Start»-Befehl mit den relevanten Parametern die am AudioControlPoint ausgegeben wird. Die Zentrale wartet auf eine erfolgreiche Statusbenachrichtigung des vorherigen «Start»-Befehls vom Peripheriegerät aus. Dadurch erhält das Peripheriegerät um die Audiowiedergabe-Pipeline vorzubereiten. Während des Audiostreamings wird das Replikat sollte bei jedem Verbindungsereignis verfügbar sein, auch wenn die aktuelle Die Replikatlatenz kann ungleich null sein.
6. Das Peripheriegerät ruft das erste Audiopaket aus der internen Warteschlange ab (Sequenznummer 0) und spielt sie ab.

Die Zentrale gibt den Befehl «Stop» aus, um die Audiostream verwenden. Nach diesem Befehl muss das Peripheriegerät nicht auf allen Verbindungsereignis an. Wenn Sie das Audiostreaming neu starten möchten, führen Sie die oben genannten Schritte aus, beginnend mit aus Schritt 5. Wenn die Zentrale nicht Audiostreaming sollte eine LE-Verbindung für GATT weiterhin aufrechterhalten werden. .

Das Peripheriegerät sollte keine Verbindung zum Zentralen aktualisieren. Um Strom zu sparen, kann die Zentrale ein Verbindungsupdate zur wenn keine Audiostreams erfolgen.