Obsługa dźwięku w aparacie słuchowym za pomocą Bluetooth LE

Aparaty słuchowe (HA) mogą mieć lepszą dostępność na urządzeniach mobilnych z systemem Android, wykorzystując zorientowane na połączenie kanały 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 pakietów. Ten bufor zapewnia jakość dźwięku dla aparatów słuchowych kosztem opóźnienia.

Projekt CoC odwołuje się do Bluetooth Core Specification Version 5 (BT). Aby zachować zgodność z podstawowymi specyfikacjami, wszystkie wartości wielobajtowe na tej stronie należy odczytywać jako little-endian.

Terminologia

  • Central - urządzenie z Androidem, które skanuje reklamy przez Bluetooth.
  • Peryferyjne — aparat słuchowy, który wysyła pakiety reklamowe przez Bluetooth.

Topologia sieci i architektura systemu

W przypadku używania CoC w aparatach słuchowych topologia sieci zakłada jedno centralne i dwa urządzenia peryferyjne, jedno lewe i jedno prawe, jak pokazano na Rysunku 1 . System audio Bluetooth postrzega lewe i prawe urządzenia peryferyjne jako pojedynczy odbiornik audio. Jeśli brakuje urządzenia peryferyjnego z powodu dopasowania mono lub utraty połączenia, centrala łączy lewy i prawy kanał audio i przesyła dźwięk do pozostałego urządzenia peryferyjnego. Jeśli centrala utraci połączenie z obydwoma urządzeniami peryferyjnymi, to centrala uzna za utracone połączenie z odbiornikiem audio. 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śli centrala nie przesyła 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 komunikację danych z serwerem GATT znajdującym się na urządzeniu peryferyjnym.

Podczas parowania i łączenia aparatów słuchowych centrala:

  • Śledź sparowane nowsze lewe i prawe urządzenia peryferyjne.
  • Załóżmy, że urządzenia peryferyjne są w użyciu, jeśli istnieje prawidłowe parowanie. Centrala podejmuje 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 zostało usunięte.

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

Wymagania systemowe

Aby prawidłowo wdrożyć CoC, aby zapewnić dobre wrażenia użytkownika, systemy Bluetooth w urządzeniach centralnych i peryferyjnych:

  • wdrożyć zgodny kontroler BT 4.2 lub nowszy. Wysoce zalecane są połączenia LE Secure Connections.
  • mieć centralną obsługę co najmniej 2 jednoczesnych łączy LE z parametrami opisanymi w formacie i taktowaniu pakietu audio .
  • mieć urządzenia peryferyjne obsługujące co najmniej 1 łącze LE z parametrami opisanymi w formacie i taktowaniu pakietu audio .
  • mieć kontrolę przepływu LE opartą na kredytach [BT tom 3, część A, sekcja 10.1]. Urządzenia powinny obsługiwać rozmiar MTU i MPS co najmniej 167 bajtów na CoC i być w stanie buforować do 8 pakietów.
  • mieć rozszerzenie długości danych LE [BT tom 6, część B, rozdział 5.1.9] z ładunkiem o wielkości co najmniej 167 bajtów.
  • mieć centralne urządzenie obsługujące polecenie aktualizacji połączenia HCI LE i zgodne z niezerowymi parametrami maximum_CE_Length i minimum_CE_Length .
  • mają centralne utrzymywanie przepustowości danych dla dwóch połączeń LE CoC z dwoma różnymi urządzeniami peryferyjnymi z interwałami połączeń i rozmiarami ładunku w formacie i czasie pakietów audio .
  • niech urządzenie peryferyjne ustawi parametry MaxRxOctets i MaxRxTime w LL_LENGTH_REQ lub LL_LENGTH_RSP na najmniejsze wymagane wartości, które są wymagane dla tych specyfikacji. Dzięki temu centrala może zoptymalizować swój harmonogram podczas obliczania ilości czasu potrzebnego na odebranie ramki.

Zdecydowanie zaleca się, aby centrala i urządzenia peryferyjne obsługiwały 2 MB PHY zgodnie ze specyfikacją BT 5.0. Centrala będzie obsługiwać łącza audio o przepustowości co najmniej 64 kbit/s na warstwach PHY 1M i 2M. Nie należy używać 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 będzie wdrażać opisaną poniżej usługę serwera GATT Audio Streaming for Hearing Aid (ASHA). Urządzenie peryferyjne będzie ogłaszać tę usługę w trybie ogólnego wykrywania, aby centrala mogła rozpoznać ujście dźwięku. Wszelkie operacje przesyłania strumieniowego audio LE wymagają szyfrowania. Strumieniowe przesyłanie dźwięku BLE składa się z następujących cech:

Charakterystyka Nieruchomości Opis
Właściwości tylko do odczytu Czytać Zobacz ReadOnlyProperties .
AudioControlPoint Pisz i pisz bez odpowiedzi Punkt kontrolny dla strumienia audio. Zobacz AudioControlPoint .
Stan dźwięku Punkt Przeczytaj/powiadom Pole raportu stanu dla punktu sterowania dźwiękiem. Kody operacyjne to:
  • 0 - Stan OK
  • -1 - Nieznane polecenie
  • -2 - Niedozwolone parametry
Tom Napisz bez odpowiedzi Bajt od -128 do 0 wskazujący poziom tłumienia do zastosowania w strumieniowym sygnale audio, w zakresie od -48 dB do 0 dB. Ustawienie -128 należy interpretować jako w pełni wyciszone, tj. najniższy nie wyciszony poziom głośności to -127, co odpowiada tłumieniu -47.625 dB. Przy ustawieniu 0, przesyłany sygnał sinusoidalny „szyna-szyna” musi odpowiadać równoważnikowi wejściowemu 100 dBSPL w aparacie słuchowym. Centrala będzie przesyłać strumień w nominalnej pełnej skali i użyć tej zmiennej do ustawienia pożądanego poziomu prezentacji w urządzeniu peryferyjnym.
LE_PSM_OUT Czytać PSM używany 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 cech:

UUID usługi : {0xFDF0}

Charakterystyka UUID
Właściwości tylko do odczytu {6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint {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 musi również wdrożyć usługę informacji o urządzeniu, aby umożliwić centrali wykrycie nazw producentów i nazw urządzeń urządzenia peryferyjnego.

Właściwości tylko do odczytu

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

Bajt Opis
0 Wersja - musi być 0x01
1 Zobacz Możliwości urządzenia .
2-9 Zobacz HiSyncId .
10 Zobacz Mapa funkcji .
11-12 Opóźnienie renderowania. Jest to czas w milisekundach, od kiedy urządzenie peryferyjne odbierze ramkę audio do momentu, gdy urządzenie peryferyjne wyrenderuje wyjście. Te bajty mogą być używane do opóźnienia wideo w celu synchronizacji z dźwiękiem.
13-14 Zarezerwowane do wykorzystania w przyszłości. Zainicjuj na zera.
15-16 Obsługiwane identyfikatory kodeków . To jest maska ​​bitowa identyfikatorów obsługiwanych kodeków. 1 w bitowej lokalizacji odpowiada obsługiwanemu kodekowi. Na przykład 0x0002 oznacza, że ​​obsługiwany jest G.722 przy 16 kHz. Wszystkie pozostałe bity powinny być ustawione na 0.

Możliwości urządzenia

Fragment Opis
0 Strona urządzenia (lewa: 0, prawa: 1).
1 Mono (0) / Binarnie (1). Wskazuje, czy urządzenie jest autonomiczne i odbiera dane mono, czy też jest częścią zestawu.
2-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. Są to Identyfikatory Firmy nadawane przez BTSIG.
2-7 Unikalny identyfikator identyfikujący zestaw aparatów słuchowych. Ten identyfikator musi być taki sam dla lewego i prawego urządzenia peryferyjnego.

Mapa funkcji

Fragment Opis
0 Obsługiwane strumieniowe przesyłanie dźwięku LE CoC (tak/nie).
1-7 Zarezerwowane (ustawione na 0).

Identyfikatory kodeków

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

ID / numer bitu Kodek i częstotliwość próbkowania Wymagana szybkość transmisji Czas klatek Obowiązkowe na centralnym (C) lub peryferyjnym (P)
0 Skryty Skryty Skryty Skryty
1 G.722 @ 16 kHz 64 kb/s Zmienny C i P
2-15 są zarezerwowane.
0 jest również zarezerwowane.

AudioControlPoint

Ten punkt kontrolny nie może być używany, gdy LE CoC jest zamknięty. Opis procedury zawiera rozdział Uruchamianie i zatrzymywanie strumienia audio .

Kod operacji Argumenty Opis
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Nakazuje urządzeniu peryferyjnemu zresetowanie kodeka i rozpoczęcie odtwarzania klatki 0. Pole kodeka wskazuje identyfikator kodeka, który ma być użyty do tego odtwarzania. Na przykład pole kodeka to „1” dla G.722 przy 16kHz.

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

Urządzenie peryferyjne nie będzie żądać aktualizacji połączenia przed otrzymaniem kodu operacyjnego «Stop» .
2 «Stop» Nic Nakazuje urządzeniu peryferyjnemu zatrzymanie renderowania dźwięku. Po tym zatrzymaniu należy rozpocząć nową sekwencję konfiguracji dźwięku, aby ponownie renderować dźwięk.
3 «Status»
  • uint8_t connected
Informuje podłączone urządzenie peryferyjne o aktualizacji stanu drugiego urządzenia peryferyjnego. Połączone pole wskazuje rodzaj aktualizacji:
  • 0 - Inne urządzenie peryferyjne odłączone
  • 1 - Podłączono inne urządzenie peryferyjne
  • 2 — Na którymkolwiek z połączeń wystąpiła aktualizacja parametrów połączenia LE

Reklamy usługi ASHA GATT

UUID usługi musi znajdować się w pakiecie ogłoszeniowym. W ogłoszeniu lub ramce odpowiedzi skanowania urządzenia peryferyjne muszą zawierać dane usługi:

Przesunięcie bajtów Nazwa Opis
0 Długość AD >= 0x09
1 Typ AD 0x16 (dane serwisowe — 16-bitowy identyfikator UUID)
2-3 UUID usługi 0xFDF0 (little-endian)

Uwaga: to jest identyfikator tymczasowy.
4 Wersja protokołu 0x01
5 Zdolność
  • 0 - lewa (0) lub prawa (1) strona
  • 1 - pojedyncze (0) lub podwójne (1) urządzenia.
  • 2-7 - zarezerwowane. Te bity muszą wynosić zero.
6-9 Skrócony HiSyncID Cztery najmniej znaczące bajty HiSyncId . Te bajty powinny być najbardziej losową częścią identyfikatora.

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

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

Podczas początkowego parowania ważne jest, aby urządzenia peryferyjne reklamowały się w wystarczająco szybkim tempie, aby urządzenie mobilne mogło szybko wykryć urządzenia peryferyjne i połączyć się z nimi.

Synchronizacja lewego i prawego urządzenia peryferyjnego

Aby pracować z Bluetooth na urządzeniach mobilnych z systemem Android, urządzenia peryferyjne są odpowiedzialne za zapewnienie ich synchronizacji. Odtwarzanie na lewym i prawym urządzeniu peryferyjnym musi być zsynchronizowane w czasie. Oba urządzenia peryferyjne muszą jednocześnie odtwarzać próbki audio ze źródła.

Urządzenia peryferyjne mogą synchronizować swój czas za pomocą numeru sekwencyjnego dołączonego 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 sekwencji. 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, dwa urządzenia peryferyjne mogą wywnioskować względny czas odtwarzania. Aby uzyskać więcej informacji o pakiecie audio, zobacz Format i czas pakietu audio .

Centrala pomaga, zapewniając wyzwalacze do urządzeń binauralnych, gdy może zajść potrzeba synchronizacji. Wyzwalacze te informują każde urządzenie peryferyjne o stanie sparowanego urządzenia peryferyjnego, gdy wystąpi operacja, która może wpłynąć na synchronizację. Wyzwalacze to:

  • Jako część polecenia «Start» AudioControlPoint, podawany jest aktualny stan połączenia drugiej strony urządzeń binauralnych.
  • Za każdym razem, gdy następuje połączenie, rozłączenie lub operacja aktualizacji parametrów połączenia na jednym urządzeniu peryferyjnym, polecenie «Status» AudioControlPoint jest wysyłane do drugiej strony urządzeń binauralnych.

Format i czas pakietu audio

Pakowanie ramek audio (bloków próbek) w pakiety umożliwia aparatowi słuchowemu uzyskanie czasu z kotwic czasowych warstwy łącza. Aby uprościć wdrożenie:

  • Ramka audio powinna zawsze odpowiadać interwałowi połączenia w czasie. Na przykład, jeśli interwał połączenia wynosi 20 ms, a częstotliwość próbkowania 16 kHz, to ramka audio powinna 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 jest zliczany z zawinięciem i umożliwia urządzeniu peryferyjnemu wykrycie niedopasowania lub niedopełnienia bufora.
  • Ramka audio powinna zawsze mieścić się w pojedynczym pakiecie LE. Ramka audio powinna być wysłana jako oddzielny pakiet L2CAP. Wielkość LE LL PDU 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 pakiet ACK mógł zarezerwować przepustowość dla retransmisji. Należy zauważyć, że pakiet audio może zostać pofragmentowany przez kontroler Bluetooth w centrali. Urządzenie peryferyjne musi być w stanie odbierać 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łączenia ustawionego przez centralę.

Format oktetu wyjściowego G.722 odwołuje się do 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 @ 16 kHz 64 kb/s 20 ms 5000/3750 nas 160 bajtów

Uruchamianie i zatrzymywanie strumienia audio

Przed uruchomieniem strumienia audio centrala odpytuje urządzenia peryferyjne i ustala wspólny kodek mianownika. Konfiguracja strumienia przebiega następnie w następującej kolejności:

  1. PSM i opcjonalnie RenderDelay są odczytywane. Te wartości mogą być buforowane przez centralę.
  2. Kanał CoC L2CAP jest otwarty – urządzenie peryferyjne początkowo przyzna 8 kredytów.
  3. Wydawana jest aktualizacja połączenia w celu przełączenia łącza na parametry wymagane dla wybranego kodeka. Centrala może wykonać tę aktualizację połączenia przed połączeniem CoC w poprzednim kroku.
  4. Zarówno host centralny, jak i host peryferyjny czekają na zdarzenie zakończenia aktualizacji.
  5. Zrestartuj koder audio i zresetuj licznik sekwencji pakietów do 0. Na AudioControlPoint wydawane jest polecenie «Start» z odpowiednimi parametrami. Centrala czeka na pomyślne powiadomienie o statusie poprzedniego polecenia «Start» z urządzenia peryferyjnego przed transmisją. To oczekiwanie daje urządzeniu peryferyjnym 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 (sekwencja numer 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ć strumieniowe przesyłanie 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 wydaje aktualizacji połączenia do centrali. Aby oszczędzać energię, centrala może zaktualizować połączenie z urządzeniem peryferyjnym, gdy nie przesyła ono strumieniowo dźwięku.