Audiounterstützung für Hörgeräte mit Bluetooth LE

Hörgeräte (HA) können auf Android-betriebenen Mobilgeräten durch die Verwendung verbindungsorientierter L2CAP-Kanäle (CoC) über Bluetooth Low Energy (BLE) besser zugänglich sein. CoC verwendet einen elastischen Puffer aus mehreren Audiopaketen, um selbst bei Paketverlusten einen stetigen Audiofluss aufrechtzuerhalten. Dieser Puffer bietet Audioqualität für Hörgeräte auf Kosten der Latenz.

Das Design von CoC referenziert die Bluetooth Core Specification Version 5 (BT). Um an den Kernspezifikationen ausgerichtet zu bleiben, werden alle Multibyte-Werte auf dieser Seite als Little-Endian gelesen.

Terminologie

  • Central – das Android-Gerät, das über Bluetooth nach Werbung sucht.
  • Peripherie – das Hörsystem, das Werbepakete über Bluetooth sendet.

Netzwerktopologie und Systemarchitektur

Bei der Verwendung von CoC für Hörgeräte geht die Netzwerktopologie von einem einzigen zentralen und zwei Peripheriegeräten aus, eines links und eines rechts, wie in Abbildung 1 zu sehen. Das Bluetooth-Audiosystem betrachtet die linken und rechten Peripheriegeräte als eine einzige Audiosenke. Wenn ein Peripheriegerät aufgrund einer monauralen Anpassung oder eines Verbindungsverlusts fehlt, mischt die Zentrale den linken und rechten Audiokanal und überträgt den Ton an das verbleibende Peripheriegerät. Wenn die Zentrale die Verbindung zu beiden Peripheriegeräten verliert, betrachtet die Zentrale die Verbindung zur Audiosenke als verloren. In diesen Fällen leitet die Zentrale Audio an einen anderen Ausgang weiter.


Abbildung 1. Topologie für die Kopplung von Hörgeräten mit Android-Mobilgeräten unter Verwendung von CoC über BLE

Wenn die Zentrale keine Audiodaten zum Peripheriegerät streamt und eine BLE-Verbindung aufrechterhalten kann, sollte die Zentrale die Verbindung zum Peripheriegerät nicht trennen. Das Aufrechterhalten der Verbindung ermöglicht die Datenkommunikation mit dem GATT-Server, der sich auf dem Peripheriegerät befindet.

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

  • Verfolgen Sie die neueren gepaarten linken und rechten Peripheriegeräte.
  • Gehen Sie davon aus, dass die Peripheriegeräte verwendet werden, wenn eine gültige Paarung vorhanden ist. Die Zentrale versucht, sich mit dem gekoppelten Gerät zu verbinden oder erneut zu verbinden, wenn die Verbindung unterbrochen wird.
  • Gehen Sie davon aus, dass die Peripheriegeräte nicht mehr verwendet werden, wenn eine Kopplung gelöscht wird.

In den oben genannten Fällen bezieht sich die Kopplung auf die Registrierung eines Satzes von Hörgeräten mit einer bestimmten UUID und Links-/Rechtskennungen im Betriebssystem, nicht auf den Bluetooth-Kopplungsprozess.

System Anforderungen

Um CoC für eine gute Benutzererfahrung richtig zu implementieren, müssen die Bluetooth-Systeme in den zentralen und peripheren Geräten:

  • Implementieren Sie einen kompatiblen BT 4.2- oder höheren Controller. LE Secure Connections wird dringend empfohlen.
  • Die Zentrale muss mindestens 2 gleichzeitige LE-Links mit Parametern unterstützen, wie sie in Audiopaketformat und -timing beschrieben sind.
  • Das Peripheriegerät muss mindestens 1 LE-Link mit den unter Format und Timing von Audiopaketen beschriebenen Parametern unterstützen.
  • haben eine auf LE-Guthaben basierende Flusssteuerung [BT Band 3, Teil A, Abschnitt 10.1]. Geräte müssen eine MTU- und MPS-Größe von mindestens 167 Byte auf CoC unterstützen und bis zu 8 Pakete puffern können.
  • haben eine LE-Datenlängenerweiterung [BT Vol 6, Teil B, Abschnitt 5.1.9] mit einer Nutzlast von mindestens 167 Bytes.
  • das zentrale Gerät den HCI LE-Verbindungsaktualisierungsbefehl unterstützen und die von Null verschiedenen Parameter maximum_CE_Length und minimum_CE_Length .
  • Lassen Sie die Zentrale den Datendurchsatz für zwei LE-CoC-Verbindungen zu zwei verschiedenen Peripheriegeräten mit den Verbindungsintervallen und Nutzlastgrößen im Audiopaketformat und -timing aufrechterhalten.
  • Lassen Sie das Peripheriegerät die MaxRxOctets und MaxRxTime Parameter in den LL_LENGTH_REQ oder LL_LENGTH_RSP Frames auf die kleinsten erforderlichen Werte setzen, die für diese Spezifikationen erforderlich sind. Dadurch kann die Zentrale ihren Zeitplaner optimieren, wenn sie die Zeitdauer berechnet, die zum Empfangen eines Rahmens benötigt wird.

Es wird dringend empfohlen, dass die zentrale und die Peripherie 2 MB PHY unterstützen, wie in der BT 5.0-Spezifikation angegeben. Die Zentrale muss Audioverbindungen von mindestens 64 kbit/s sowohl auf 1M- als auch auf 2M-PHYs unterstützen. Der BLE-Langstrecken-PHY darf nicht verwendet werden.

CoC verwendet die Standard-Bluetooth-Mechanismen für Link-Layer-Verschlüsselung und Frequenzsprungverfahren.

ASHA GATT-Dienste

Ein Peripheriegerät soll den unten beschriebenen GATT-Serverdienst Audio Streaming for Hearing Aid (ASHA) implementieren. Das Peripheriegerät soll diesen Dienst ankündigen, wenn es sich im allgemein erkennbaren Modus befindet, damit die Zentrale eine Audiosenke erkennen kann. Alle LE-Audio-Streaming-Vorgänge müssen verschlüsselt werden. Das BLE-Audio-Streaming besteht aus folgenden Merkmalen:

Charakteristisch Eigenschaften Beschreibung
ReadOnlyProperties Lesen Siehe ReadOnlyProperties .
AudioControlPoint Schreiben und schreiben ohne Antwort Kontrollpunkt für Audiostream. Siehe AudioControlPoint .
AudioStatusPoint Lesen/benachrichtigen Statusberichtsfeld für den Audiokontrollpunkt. Opcodes sind:
  • 0 - Status in Ordnung
  • -1 - Unbekannter Befehl
  • -2 - Unzulässige Parameter
Volumen Schreiben Sie ohne Antwort Byte zwischen -128 und 0, das den Dämpfungsgrad angibt, der auf das gestreamte Audiosignal angewendet werden soll, im Bereich von -48 dB bis 0 dB. Die Einstellung -128 wird als vollständig stumm interpretiert, dh der niedrigste nicht stummgeschaltete Lautstärkepegel ist -127, was einer Dämpfung von -47,625 dB entspricht. Bei Einstellung 0 entspricht ein gestreamter Rail-to-Rail-Sinuston einem Eingangsäquivalent von 100 dBSPL am Hörsystem. Die Zentrale soll in nomineller Vollaussteuerung streamen und diese Variable verwenden, um den gewünschten Präsentationspegel in der Peripherie einzustellen.
LE_PSM_OUT Lesen PSM zum Anschluss des Audiokanals. Zu entnehmen aus dem Dynamikbereich [BT Vol 3, Part A, Sec 4.22]

Die dem Dienst zugeordneten UUIDs und Merkmale:

Dienst-UUID : {0xFDF0}

Charakteristisch UUID
ReadOnlyProperties {6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint {f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
AudioStatus {38663f1a-e711-4cac-b641-326b56404837}
Volumen {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 implementieren, damit die Zentrale die Herstellernamen und Gerätenamen des Peripheriegeräts erkennen kann.

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 Renderverzögerung. Dies ist die Zeit in Millisekunden, ab der das Peripheriegerät einen Audioframe empfängt, bis das Peripheriegerät die Ausgabe rendert. Diese Bytes können verwendet werden, um ein Video zu verzögern, um es mit dem Audio zu synchronisieren.
13-14 Reserviert für zukünftige Verwendung. Auf Null initialisieren.
15-16 Unterstützte Codec-IDs . Dies ist eine Bitmaske unterstützter Codec-IDs. Eine 1 an einer Bitstelle entspricht einem unterstützten Codec. Beispielsweise zeigt 0x0002 an, dass G.722 bei 16 kHz unterstützt wird. Alle anderen Bits sind auf 0 zu setzen.

Gerätefähigkeiten

Bisschen Beschreibung
0 Geräteseite (Links: 0, Rechts: 1).
1 Mono (0) / Binaural (1). Zeigt an, ob das Gerät eigenständig ist und Mono-Daten empfängt, oder ob das Gerät Teil eines Sets ist.
2-7 Reserviert (auf 0 gesetzt).

HiSyncID

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

Byte Beschreibung
0-1 ID des Herstellers. Es handelt sich um die von BTSIG zugewiesenen Firmenkennungen.
2-7 Eindeutige ID, die das Hörgeräteset identifiziert. Diese ID muss sowohl am linken als auch am rechten Peripheriegerät gleich eingestellt sein.

FeatureMap

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

Codec-IDs

Wenn das Bit gesetzt ist, wird dieser bestimmte Codec unterstützt.

ID / Bitnummer Codec und Abtastrate Erforderliche Bitrate Rahmenzeit Obligatorisch bei Zentral (C) oder Peripherie (P)
0 Reserviert Reserviert Reserviert Reserviert
1 G.722 bei 16 kHz 64kbit/s Variable C und P
2-15 sind reserviert.
0 ist ebenfalls reserviert.

AudioControlPoint

Dieser Kontrollpunkt kann nicht verwendet werden, wenn das LE CoC geschlossen ist. Siehe Starten und Stoppen eines Audiostreams für die Beschreibung des Verfahrens.

Opcode Argumente Beschreibung
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Weist das Peripheriegerät an, den Codec zurückzusetzen und die Wiedergabe von Frame 0 zu starten. Das Codec-Feld gibt die Codec-ID an, die für diese Wiedergabe verwendet werden soll. Beispielsweise ist das Codec-Feld „1“ für G.722 bei 16 kHz.

Das Audiotyp-Bitfeld gibt den/die im Stream vorhandenen Audiotyp(en) an:
  • 0 - Unbekannt
  • 1 - Klingelton
  • 2 - Telefonanruf
  • 3 - Medien
Das otherstate -Feld zeigt an, ob die andere Seite der binauralen Geräte angeschlossen ist. Der Feldwert ist 1, wenn das andere Peripheriegerät angeschlossen ist, ansonsten ist der Wert 0.

Das Peripheriegerät darf keine Verbindungsaktualisierungen anfordern, bevor ein «Stop» -Opcode empfangen wurde.
2 «Stop» Keiner Weist das Peripheriegerät an, die Wiedergabe von Audio zu beenden. Nach diesem Stopp sollte eine neue Audio-Setup-Sequenz initiiert werden, um Audio erneut zu rendern.
3 «Status»
  • uint8_t connected
Informiert das angeschlossene Peripheriegerät, dass es eine Statusaktualisierung auf dem anderen Peripheriegerät gibt. Das verbundene Feld zeigt die Art der Aktualisierung an:
  • 0 - Anderes Peripheriegerät getrennt
  • 1 - Anderes Peripheriegerät angeschlossen
  • 2 - Bei beiden Verbindungen ist eine LE-Verbindungsparameteraktualisierung aufgetreten

Werbung für ASHA GATT Service

Die Dienst-UUID muss im Ankündigungspaket enthalten sein. Entweder in der Ankündigung oder im Scan-Antwortrahmen müssen die Peripheriegeräte über Servicedaten verfügen:

Byte-Offset Name Beschreibung
0 AD-Länge >= 0x09
1 AD-Typ 0x16 (Servicedaten – 16-Bit-UUID)
2-3 Dienst-UUID 0xFDF0 (Little-Endian)

Hinweis: Dies ist eine temporäre ID.
4 Protokollversion 0x01
5 Fähigkeit
  • 0 - linke (0) oder rechte (1) Seite
  • 1 - einzelne (0) oder duale (1) Geräte.
  • 2-7 - reserviert. Diese Bits müssen Null sein.
6-9 Abgeschnittene HiSyncID Vier niedrigstwertige Bytes der HiSyncId . Diese Bytes sollten der zufälligste Teil der ID sein.

Die Peripheriegeräte müssen einen Datentyp „ Complete Local Name “ haben, der den Namen des Hörgeräts angibt. Dieser Name wird auf der Benutzeroberfläche des Mobilgeräts verwendet, damit der Benutzer das richtige Gerät auswählen kann. Der Name darf nicht den linken oder rechten Kanal angeben, da diese Informationen in DeviceCapabilities bereitgestellt werden.

Wenn die Peripheriegeräte den Namen und die ASHA-Dienstdatentypen in denselben Rahmentyp (ADV oder SCAN RESP) setzen, dann sollen die zwei Datentypen ("Vollständiger lokaler Name" und "Dienstdaten für ASHA-Dienst") in demselben Rahmen erscheinen. Dadurch erhält der Mobilgerätescanner beide Daten in demselben Scanergebnis.

Während der anfänglichen Kopplung ist es wichtig, dass die Peripheriegeräte mit einer Rate ankündigen, die schnell genug ist, damit das mobile Gerät die Peripheriegeräte schnell erkennen und sich mit ihnen verbinden kann.

Synchronisieren von linken und rechten Peripheriegeräten

Um mit Bluetooth auf Android-Mobilgeräten zu arbeiten, müssen Peripheriegeräte sicherstellen, dass sie synchronisiert sind. Die Wiedergabe auf den linken und rechten Peripheriegeräten muss zeitlich synchronisiert werden. Beide Peripheriegeräte müssen gleichzeitig Audio-Samples von der Quelle wiedergeben.

Peripheriegeräte können ihre Zeit synchronisieren, indem sie eine Sequenznummer verwenden, die jedem Paket der Audio-Nutzlast vorangestellt wird. Die Zentrale garantiert, dass Audiopakete, die gleichzeitig auf jedem Peripheriegerät abgespielt werden sollen, dieselbe Sequenznummer haben. Die Sequenznummer wird nach jedem Audiopaket um eins erhöht. Jede Sequenznummer ist 8 Bit lang, sodass sich die Sequenznummern nach 256 Audiopaketen wiederholen. Da jede Audiopaketgröße und Abtastrate für jede Verbindung festgelegt ist, können die beiden Peripheriegeräte die relative Spielzeit ableiten. Weitere Informationen zum Audiopaket finden Sie unter Audiopaketformat und -timing .

Die Zentrale hilft, indem sie den binauralen Geräten Auslöser bereitstellt, wenn die Synchronisation möglicherweise stattfinden muss. Diese Trigger informieren jedes Peripheriegerät über den Status seines gepaarten Peripheriegeräts, wann immer es eine Operation gibt, die die Synchronisation beeinflussen könnte. Die Auslöser sind:

  • Im Rahmen des «Start» -Befehls von AudioControlPoint wird der aktuelle Verbindungszustand der Gegenseite der binauralen Geräte angegeben.
  • Wann immer eine Verbindung, Trennung oder Aktualisierung der Verbindungsparameter an einem Peripheriegerät stattfindet, wird der «Status» -Befehl von AudioControlPoint an die andere Seite der binauralen Geräte gesendet.

Format und Timing von Audiopaketen

Durch das Packen von Audio-Frames (Sample-Blöcken) in Pakete kann das Hörgerät das Timing von den Timing-Ankern der Verbindungsschicht ableiten. Um die Implementierung zu vereinfachen:

  • Ein Audioframe sollte zeitlich immer mit dem Verbindungsintervall übereinstimmen. Wenn beispielsweise das Verbindungsintervall 20 ms und die Abtastrate 16 kHz beträgt, dann soll der Audiorahmen 320 Abtastungen enthalten.
  • Abtastraten im System sind auf Vielfache von 8 kHz beschränkt, um immer eine ganzzahlige Anzahl von Abtastungen in einem Rahmen zu haben, unabhängig von der Rahmenzeit oder dem Verbindungsintervall.
  • Audioframes soll ein Sequenzbyte vorangestellt werden. Das Folgebyte soll mit Umlauf gezählt werden und es dem Peripheriegerät ermöglichen, eine Pufferfehlanpassung oder einen Unterlauf zu erkennen.
  • Ein Audiorahmen soll immer in ein einzelnes LE-Paket passen. Der Audioframe soll als separates L2CAP-Paket gesendet werden. Die Größe der LE LL PDU muss sein:
    Audionutzlastgröße + 1 (Sequenzzähler) + 6 (4 für L2CAP-Header, 2 für SDU)
  • Ein Verbindungsereignis sollte immer groß genug sein, um 2 Audiopakete und 2 leere Pakete für ein ACK zu enthalten, um Bandbreite für Neuübertragungen zu reservieren. Beachten Sie, dass das Audiopaket möglicherweise vom Bluetooth-Controller der Zentrale fragmentiert wird. Das Peripheriegerät muss in der Lage sein, mehr als 2 fragmentierte Audiopakete pro Verbindungsereignis zu empfangen.

Um der Zentrale eine gewisse Flexibilität zu geben, wird die G.722-Paketlänge nicht angegeben. Die G.722-Paketlänge kann sich basierend auf dem von der Zentrale festgelegten Verbindungsintervall ändern.

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

Für alle Codecs, die ein Peripheriegerät unterstützt, soll das Peripheriegerät die nachstehenden Verbindungsparameter unterstützen. Dies ist eine nicht erschöpfende Liste von Konfigurationen, die die Zentrale implementieren kann.

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

Starten und Stoppen eines Audiostreams

Vor dem Starten eines Audiostroms fragt die Zentrale die Peripheriegeräte ab und stellt einen gemeinsamen Nenner-Codec her. Das Stream-Setup durchläuft dann die folgende Sequenz:

  1. PSM und optional RenderDelay wird gelesen. Diese Werte können von der Zentrale zwischengespeichert werden.
  2. Der CoC L2CAP-Kanal wird geöffnet – das Peripheriegerät gewährt zunächst 8 Credits.
  3. Es wird eine Verbindungsaktualisierung ausgegeben, um die Verbindung auf die für den ausgewählten Codec erforderlichen Parameter umzuschalten. Die Zentrale kann diese Verbindungsaktualisierung vor der CoC-Verbindung im vorherigen Schritt durchführen.
  4. Sowohl der zentrale als auch der periphere Host warten auf das Update-Complete-Ereignis.
  5. Starten Sie den Audio-Encoder neu und setzen Sie den Paketsequenzzähler auf 0 zurück. Auf dem AudioControlPoint wird ein «Start» -Befehl mit den entsprechenden Parametern ausgegeben. Die Zentrale wartet vor dem Streaming auf eine erfolgreiche Statusmeldung des vorangegangenen «Start» -Befehls vom Peripheriegerät. Dieses Warten gibt dem Peripheriegerät Zeit, seine Audiowiedergabe-Pipeline vorzubereiten. Während des Audiostreamings sollte die Kopie bei jedem Verbindungsereignis verfügbar sein, auch wenn die aktuelle Replikatlatenz möglicherweise nicht Null ist.
  6. Das Peripheriegerät nimmt das erste Audiopaket aus seiner internen Warteschlange (Sequenznummer 0) und spielt es ab.

Die Zentrale gibt den Befehl «Stop» , um den Audiostream zu beenden. Nach diesem Befehl muss das Peripheriegerät nicht bei jedem Verbindungsereignis verfügbar sein. Um das Audio-Streaming neu zu starten, führen Sie die obige Sequenz ab Schritt 5 durch. Wenn die Zentrale kein Audio-Streaming durchführt, sollte sie dennoch eine LE-Verbindung für GATT-Dienste aufrechterhalten.

Das Peripheriegerät darf keine Verbindungsaktualisierung an die Zentrale ausgeben. Um Strom zu sparen, kann die Zentrale eine Verbindungsaktualisierung an das Peripheriegerät ausgeben, wenn es kein Audio-Streaming durchführt.