Obsługa dźwięku w aparatach słuchowych za pomocą Bluetooth LE

Aparaty słuchowe (HA) mogą mieć lepszą dostępność na urządzeniach mobilnych z systemem Android dzięki wykorzystaniu zorientowanych na połączenie kanałów L2CAP (CoC) przez Bluetooth Low Energy (BLE). CoC wykorzystuje elastyczny bufor kilku pakietów audio, aby utrzymać stały przepływ dźwięku, nawet w przypadku utraty pakietu. Bufor ten zapewnia jakość dźwięku dla aparatów słuchowych kosztem opóźnień.

Projekt CoC nawiązuje do specyfikacji rdzenia Bluetooth w wersji 5 (BT). Aby zachować zgodność z podstawowymi specyfikacjami, wszystkie wartości wielobajtowe na tej stronie należy odczytywać jako small-endian.

Terminologia

  • Centrala – urządzenie z Androidem, które skanuje reklamy przez Bluetooth.
  • Urządzenie peryferyjne – aparat słuchowy wysyłający pakiety reklam przez Bluetooth.

Topologia sieci i architektura systemu

W przypadku stosowania CoC w aparatach słuchowych topologia sieci zakłada jeden centralny i dwa urządzenia peryferyjne, jedno lewe i jedno prawe, jak pokazano na rysunku 1 . System audio Bluetooth traktuje lewe i prawe urządzenie peryferyjne jako pojedynczy odbiornik audio. Jeśli brakuje urządzenia peryferyjnego z powodu dopasowania monofonicznego lub utraty połączenia, urządzenie centralne miksuje lewy i prawy kanał audio i przesyła dźwięk do pozostałego urządzenia peryferyjnego. Jeżeli centrala utraci połączenie z obydwoma urządzeniami peryferyjnymi, wówczas uzna, że ​​połączenie z odbiornikiem audio zostało utracone. W takich przypadkach centrala kieruje dźwięk do innego wyjścia.


Rysunek 1. Topologia parowania aparatów słuchowych z urządzeniami mobilnymi z systemem Android przy użyciu CoC przez BLE

Jeżeli centrala nie przesyła strumieniowo danych audio do urządzenia peryferyjnego i może utrzymywać połączenie BLE, centrala nie powinna odłączać się od urządzenia peryferyjnego. Utrzymanie połączenia umożliwia przesyłanie danych do serwera GATT znajdującego się na urządzeniu peryferyjnym.

Podczas parowania i podłączania aparatów słuchowych centrala powinna:

  • Śledź najnowsze sparowane lewe i prawe urządzenia peryferyjne.
  • Załóżmy, że urządzenia peryferyjne są używane, jeśli istnieje prawidłowe parowanie. Centrala podejmie próbę połączenia lub ponownego połączenia ze sparowanym urządzeniem w przypadku utraty połączenia.
  • Załóżmy, że urządzenia peryferyjne nie są już używane, jeśli parowanie zostanie usunięte.

W powyższych przypadkach parowanie odnosi się do czynności polegającej na zarejestrowaniu zestawu aparatów słuchowych z danym UUID i oznaczeniami lewy/prawy w systemie operacyjnym, a nie procesem parowania Bluetooth.

Wymagania systemowe

Aby prawidłowo wdrożyć CoC w celu zapewnienia dobrego doświadczenia użytkownika, systemy Bluetooth w urządzeniach centralnych i peryferyjnych powinny:

  • wdrożyć kontroler zgodny z BT 4.2 lub nowszym. Zdecydowanie zalecamy LE Secure Connections.
  • posiadać centralę obsługującą co najmniej 2 jednoczesne łącza LE z parametrami opisanymi w sekcji Format pakietu audio i synchronizacja .
  • posiadać urządzenie peryferyjne obsługujące co najmniej 1 łącze LE o parametrach opisanych w części Format pakietu audio i taktowanie .
  • posiadać kontrolę przepływu opartą na kredytach LE [BT tom 3, część A, rozdz. 10.1]. Urządzenia powinny obsługiwać rozmiar MTU i MPS co najmniej 167 bajtów w CoC i być w stanie buforować do 8 pakietów.
  • mieć rozszerzenie długości danych LE [BT tom 6, część B, rozdz. 5.1.9] z ładunkiem co najmniej 167 bajtów.
  • czy urządzenie centralne obsługuje polecenie aktualizacji połączenia HCI LE i jest zgodne z niezerowymi parametrami maximum_CE_Length i minimum_CE_Length .
  • zlecić centrali utrzymywanie przepustowości danych dla dwóch połączeń LE CoC z dwoma różnymi urządzeniami peryferyjnymi z uwzględnieniem interwałów połączeń i rozmiarów ładunku w formacie pakietu audio i taktowaniu .
  • niech urządzenie peryferyjne ustawi parametry MaxRxOctets i MaxRxTime w ramkach LL_LENGTH_REQ lub LL_LENGTH_RSP na najmniejsze wymagane wartości, które są niezbędne dla tych specyfikacji. Pozwala to centrali zoptymalizować harmonogram przy obliczaniu ilości czasu potrzebnego na odebranie ramki.

Zdecydowanie zaleca się, aby centrala i urządzenia peryferyjne obsługiwały 2MB PHY zgodnie ze specyfikacją BT 5.0. Centrala będzie obsługiwać łącza audio o szybkości co najmniej 64 kbit/s zarówno w warstwach PHY 1M, jak i 2M. Nie należy stosować PHY dalekiego zasięgu BLE.

CoC wykorzystuje standardowe mechanizmy Bluetooth do szyfrowania warstwy łącza i przeskakiwania częstotliwości.

Usługi ASHA GATT

Urządzenie peryferyjne powinno implementować opisaną poniżej usługę serwera przesyłania strumieniowego audio dla aparatów słuchowych (ASHA) GATT. Urządzenie peryferyjne będzie reklamować tę usługę, gdy będzie w trybie ogólnego wykrywania, aby umożliwić centrali rozpoznanie pochłaniacza sygnału audio. Wszelkie operacje przesyłania strumieniowego audio LE wymagają szyfrowania. Strumieniowe przesyłanie dźwięku BLE charakteryzuje się następującymi cechami:

Charakterystyka Nieruchomości Opis
Właściwości tylko do odczytu Czytać Zobacz ReadOnlyProperties .
Punkt kontrolny audio Pisz i pisz bez odpowiedzi Punkt kontrolny dla strumienia audio. Zobacz AudioControlPoint .
Punkt stanu dźwięku Przeczytaj/Powiadom Pole raportu stanu dla punktu sterowania dźwiękiem. Zobacz AudioStatusPoint
Tom Napisz bez odpowiedzi Bajt od -128 do 0 wskazujący stopień tłumienia, jaki należy zastosować do przesyłanego strumieniowo sygnału audio, w zakresie od -48 dB do 0 dB. Ustawienie -128 należy interpretować jako całkowicie wyciszone, tj. najniższy poziom głośności, który nie jest wyciszony, to -127, co odpowiada tłumieniu -47,625 dB. Przy ustawieniu 0, przesyłany strumieniowo sinusoidalny ton typu „rail-to-rail” będzie odpowiadał wejściu aparatu słuchowego na poziomie 100 dBSPL. Centrala będzie przesyłać strumieniowo w nominalnej pełnej skali i użyje tej zmiennej do ustawienia pożądanego poziomu prezentacji w urządzeniu peryferyjnym.
LE_PSM_OUT Czytać PSM do podłączenia kanału audio. Do wyboru z zakresu dynamicznego [BT tom 3, część A, rozdz. 4.22]

Identyfikatory UUID przypisane do usługi i charakterystyki:

Identyfikator UUID usługi : {0xFDF0}

Charakterystyka UUID
Właściwości tylko do odczytu {6333651e-c481-4a3e-9169-7c902aad37bb}
Punkt kontrolny audio {f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
Stan dźwięku {38663f1a-e711-4cac-b641-326b56404837}
Tom {00e4ca9e-ab14-41e4-8823-f9e70c7e91df}
LE_PSM_OUT {2d410339-82b6-42aa-b34e-e2e01df8cc1a}

Oprócz usługi ASHA GATT urządzenie peryferyjne powinno także wdrożyć usługę informacji o urządzeniu, umożliwiającą centrali wykrywanie nazw producentów i nazw urządzeń peryferyjnych.

Właściwości tylko do odczytu

ReadOnlyProperties mają następujące wartości:

Bajt Opis
0 Wersja — musi mieć wartość 0x01
1 Zobacz Możliwości urządzenia .
2-9 Zobacz HiSyncId .
10 Zobacz Mapę Funkcji .
11-12 Opóźnienie renderowania. Jest to czas w milisekundach, jaki upływa od odebrania ramki audio przez urządzenie peryferyjne do chwili wyrenderowania sygnału wyjściowego. Te bajty można wykorzystać do opóźnienia synchronizacji wideo z dźwiękiem.
13-14 Zarezerwowane do wykorzystania w przyszłości. Zainicjuj do zer.
15-16 Obsługiwane identyfikatory kodeków . To jest maska ​​bitowa obsługiwanych identyfikatorów kodeków. Lokalizacja bitowa 1 odpowiada obsługiwanemu kodekowi. Na przykład 0x0002 wskazuje, że obsługiwany jest standard G.722 przy 16 kHz. Wszystkie pozostałe bity należy ustawić na 0.

Możliwości urządzenia

Fragment Opis
0 Strona urządzenia (0: lewa, 1: prawa)
1 Wskazuje, czy urządzenie jest samodzielne i odbiera dane w trybie mono, czy też jest częścią zestawu (0: mono, 1: binaural)
2 Urządzenie obsługuje CSIS (0: nieobsługiwane, 1: obsługiwane)
3-7 Zarezerwowane (ustawione na 0)

HiSyncID

To pole musi być unikalne dla wszystkich urządzeń binauralnych, ale musi być takie samo dla lewego i prawego zestawu.

Bajt Opis
0-1 Identyfikator producenta. Jest to Identyfikator Firmy nadawany przez BTSIG.
2-7 Unikalny identyfikator identyfikujący zestaw aparatów słuchowych. Ten identyfikator musi być ustawiony na taki sam zarówno po lewej, jak i po prawej stronie urządzenia peryferyjnego.

Mapa funkcji

Fragment Opis
0 Obsługiwane strumieniowe przesyłanie sygnału wyjściowego audio LE CoC (tak/nie).
1-7 Zarezerwowane (ustawione na 0).

Identyfikatory kodeków

Jeśli bit jest ustawiony, obsługiwany jest ten konkretny kodek.

Numer identyfikacyjny / bitowy Kodek i częstotliwość próbkowania Wymagana szybkość transmisji Czas ramki Obowiązkowe na centralnym (C) lub peryferyjnym (P)
0 Skryty Skryty Skryty Skryty
1 G.722 przy 16 kHz 64 kbit/s Zmienny C i P
2-15 jest zarezerwowanych.
0 jest również zarezerwowane.

Punkt kontrolny audio

Tego punktu kontrolnego nie można używać, gdy LE CoC jest zamknięty. Opis procedury można znaleźć w sekcji Uruchamianie i zatrzymywanie strumienia audio .

Kod operacji Argumenty Podprocedura GATT Opis
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Napisz z odpowiedzią i spodziewaj się dodatkowego powiadomienia o statusie poprzez charakterystykę AudioStatusPoint . Nakazuje urządzeniu peryferyjnemu zresetowanie kodeka i rozpoczęcie odtwarzania klatki 0. Pole kodeka wskazuje identyfikator kodeka, który ma zostać użyty do tego odtwarzania. Na przykład pole kodeka ma wartość „1” dla G.722 przy 16 kHz.

Pole bitowe typu audio wskazuje typy audio obecne w strumieniu:
  • 0 - Nieznane
  • 1 - Dzwonek
  • 2 - Rozmowa telefoniczna
  • 3 - Media
Pole innego stanu wskazuje, czy podłączona jest druga strona urządzeń binauralnych. Wartość pola wynosi 1, gdy podłączone jest drugie urządzenie peryferyjne, w przeciwnym razie wartość wynosi 0.

Urządzenie peryferyjne nie będzie żądać aktualizacji połączenia przed otrzymaniem kodu operacji «Stop» .
2 «Stop» Nic Napisz z odpowiedzią i spodziewaj się dodatkowego powiadomienia o statusie poprzez charakterystykę AudioStatusPoint . Nakazuje urządzeniu peryferyjnemu zatrzymanie renderowania dźwięku. Po tym zatrzymaniu należy rozpocząć nową sekwencję konfiguracji dźwięku, aby ponownie wyrenderować dźwięk.
3 «Status»
  • uint8_t connected
Napisz bez odpowiedzi Informuje podłączone urządzenie peryferyjne, że na drugim urządzeniu peryferyjnym trwa aktualizacja stanu. Połączone pole wskazuje typ aktualizacji:
  • 0 - Inne urządzenie peryferyjne odłączone
  • 1 - Podłączono inne urządzenie peryferyjne
  • 2 - Na którymkolwiek połączeniu wystąpiła aktualizacja parametrów połączenia LE

Punkt stanu dźwięku

Pole raportu stanu dla punktu sterowania dźwiękiem

Kody operacyjne Opis
0 Stan OK
-1 Nieznane polecenie
-2 Niedozwolone parametry

Reklamy usługi ASHA GATT

UUID usługi musi znajdować się w pakiecie reklamowym. Zarówno w ogłoszeniu, jak i w ramce odpowiedzi na skanowanie urządzenia peryferyjne muszą zawierać dane serwisowe:

Przesunięcie bajtu Nazwa Opis
0 Długość reklamy >= 0x09
1 Typ reklamy 0x16 (dane serwisowe — 16-bitowy identyfikator UUID)
2-3 UUID usługi 0xFDF0 (mały koniec)

Uwaga: jest to identyfikator tymczasowy.
4 Wersja protokołu 0x01
5 Zdolność
  • 0 - lewa (0) lub prawa (1) strona
  • 1 - urządzenia pojedyncze (0) lub podwójne (1).
  • 2 - urządzenie obsługuje CSIS (<0: nieobsługiwane, 1: obsługiwane)
  • 3-7 - zarezerwowane. Te bity muszą wynosić zero.
6-9 Obcięty HiSyncID Cztery najmniej znaczące bajty HiSyncId . Te bajty powinny stanowić najbardziej losową część identyfikatora.

Urządzenia peryferyjne muszą mieć typ danych Pełna nazwa lokalna , który wskazuje nazwę aparatu słuchowego. Nazwa ta będzie używana w interfejsie użytkownika urządzenia mobilnego, aby użytkownik mógł wybrać odpowiednie urządzenie. Nazwa nie wskazuje lewego ani prawego kanału, ponieważ informacja ta jest podana w DeviceCapabilities .

Jeżeli urządzenia peryferyjne umieścią nazwę i typy danych usługi ASHA w tym samym typie ramki (ADV lub SCAN RESP), wówczas oba typy danych („Pełna nazwa lokalna” i „Dane usługi dla usługi ASHA”) pojawią się w tej samej ramce. Dzięki temu skaner urządzenia mobilnego uzyska oba dane w tym samym wyniku skanowania.

Podczas pierwszego parowania ważne jest, aby urządzenia peryferyjne ogłaszały się z wystarczająco dużą szybkością, aby umożliwić urządzeniu mobilnemu szybkie wykrycie urządzeń peryferyjnych i nawiązanie z nimi połączenia.

Synchronizacja lewego i prawego urządzenia peryferyjnego

Aby móc pracować z technologią Bluetooth na urządzeniach mobilnych z systemem Android, urządzenia peryferyjne odpowiadają za ich synchronizację. Odtwarzanie na lewym i prawym urządzeniu peryferyjnym musi być zsynchronizowane w czasie. Obydwa urządzenia peryferyjne muszą odtwarzać próbki audio ze źródła w tym samym czasie.

Urządzenia peryferyjne mogą synchronizować swój czas za pomocą numeru sekwencyjnego dołączanego do każdego pakietu ładunku audio. Centrala gwarantuje, że pakiety audio, które mają być odtwarzane w tym samym czasie na każdym urządzeniu peryferyjnym, mają ten sam numer sekwencyjny. Numer sekwencyjny zwiększa się o jeden po każdym pakiecie audio. Każdy numer sekwencyjny ma długość 8 bitów, więc numery sekwencyjne będą się powtarzać po 256 pakietach audio. Ponieważ każdy rozmiar pakietu audio i częstotliwość próbkowania są stałe dla każdego połączenia, oba urządzenia peryferyjne mogą wywnioskować względny czas odtwarzania. Aby uzyskać więcej informacji na temat pakietu audio, zobacz Format i synchronizacja pakietu audio .

Centrala pomaga, wyzwalając urządzenia binauralne, gdy może zaistnieć potrzeba synchronizacji. Wyzwalacze te informują każde urządzenie peryferyjne o stanie sparowanego urządzenia peryferyjnego za każdym razem, gdy ma miejsce operacja, która może mieć wpływ na synchronizację. Wyzwalacze to:

  • W ramach polecenia «Start» programu AudioControlPoint podawany jest aktualny stan połączenia drugiej strony urządzeń binauralnych.
  • Za każdym razem, gdy na jednym urządzeniu peryferyjnym następuje połączenie, rozłączenie lub aktualizacja parametrów połączenia, polecenie «Status» z AudioControlPoint jest wysyłane na drugą stronę urządzeń binauralnych.

Format i synchronizacja pakietu audio

Pakowanie ramek audio (bloków próbek) w pakiety umożliwia aparatowi słuchowemu określenie taktowania na podstawie kotwic taktowania warstwy łącza. Aby uprościć implementację:

  • Ramka audio powinna zawsze odpowiadać odstępowi czasowemu połączenia. Na przykład, jeśli interwał połączenia wynosi 20 ms, a częstotliwość próbkowania wynosi 16 kHz, wówczas ramka audio będzie zawierać 320 próbek.
  • Częstotliwości próbkowania w systemie są ograniczone do wielokrotności 8 kHz, aby zawsze mieć całkowitą liczbę próbek w ramce, niezależnie od czasu ramki lub interwału połączenia.
  • Bajt sekwencji powinien poprzedzać ramki audio. Bajt sekwencji powinien być zliczany z zawijaniem i umożliwiać urządzeniu peryferyjnemu wykrycie niedopasowania bufora lub niedopełnienia.
  • Ramka audio powinna zawsze mieścić się w pojedynczym pakiecie LE. Ramka audio będzie wysyłana jako oddzielny pakiet L2CAP. Rozmiar LE LL PDU powinien wynosić:
    rozmiar ładunku audio + 1 (licznik sekwencji) + 6 (4 dla nagłówka L2CAP, 2 dla SDU)
  • Zdarzenie połączenia powinno zawsze być wystarczająco duże, aby zawierać 2 pakiety audio i 2 puste pakiety, aby potwierdzenie ACK mogło zarezerwować przepustowość dla retransmisji. Należy pamiętać, że pakiet audio może być fragmentowany przez kontroler Bluetooth centrali. Urządzenie peryferyjne musi być w stanie odebrać więcej niż 2 pofragmentowane pakiety audio na zdarzenie połączenia.

Aby zapewnić centrali pewną elastyczność, długość pakietu G.722 nie jest określona. Długość pakietu G.722 może się zmieniać w zależności od interwału połączeń ustawionego przez centralę.

Format oktetu wyjściowego G.722 odwołuje się do formatu Rec. ITU-T G.722 (09/2012), sekcja 1.4.4 „Multiplekser”

W przypadku wszystkich kodeków obsługiwanych przez urządzenie peryferyjne urządzenie peryferyjne powinno obsługiwać poniższe parametry połączenia. Jest to niewyczerpująca lista konfiguracji, które może wdrożyć centrala.

Kodek Szybkość transmisji Interwał połączenia Długość CE (1M/2M PHY) Rozmiar ładunku audio
G.722 przy 16 kHz 64 kbit/s 20 ms 5000/3750 nas 160 bajtów

Uruchamianie i zatrzymywanie strumienia audio

Przed uruchomieniem strumienia audio jednostka centralna wysyła zapytanie do urządzeń peryferyjnych i ustala wspólny kodek mianownika. Następnie konfiguracja strumienia przebiega w następującej kolejności:

  1. PSM i opcjonalnie RenderDelay jest odczytywany. Wartości te mogą być buforowane przez centralę.
  2. Kanał CoC L2CAP jest otwarty – urządzenie peryferyjne przyzna początkowo 8 kredytów.
  3. Wydawana jest aktualizacja połączenia w celu przełączenia łącza na parametry wymagane dla wybranego kodeka. Centrala może dokonać tej aktualizacji połączenia przed połączeniem CoC w poprzednim kroku.
  4. Zarówno host centralny, jak i peryferyjny czekają na zdarzenie zakończenia aktualizacji.
  5. Uruchom ponownie koder audio i zresetuj liczbę sekwencji pakietów do 0. Na AudioControlPoint wydawane jest polecenie «Start» z odpowiednimi parametrami. Centrala czeka na pomyślne powiadomienie o statusie wcześniejszego polecenia «Start» z urządzenia peryferyjnego przed rozpoczęciem transmisji strumieniowej. To oczekiwanie daje urządzeniu peryferyjnemu czas na przygotowanie potoku odtwarzania dźwięku. Podczas przesyłania strumieniowego audio replika powinna być dostępna przy każdym zdarzeniu połączenia, nawet jeśli bieżące opóźnienie repliki może być niezerowe.
  6. Urządzenie peryferyjne pobiera pierwszy pakiet audio ze swojej kolejki wewnętrznej (numer kolejny 0) i odtwarza go.

Centrala wydaje polecenie «Stop» , aby zamknąć strumień audio. Po tym poleceniu urządzenie peryferyjne nie musi być dostępne przy każdym zdarzeniu połączenia. Aby ponownie uruchomić strumieniowanie dźwięku, wykonaj powyższą sekwencję, zaczynając od kroku 5. Jeśli centrala nie przesyła strumieniowo dźwięku, powinna nadal utrzymywać połączenie LE dla usług GATT.

Urządzenie peryferyjne nie będzie wysyłać aktualizacji połączenia do centrali. Aby oszczędzać energię, centrala może wysłać aktualizację połączenia do urządzenia peryferyjnego, gdy nie przesyła ono strumieniowo dźwięku.