Aparaty słuchowe mogą mieć lepszą dostępność na urządzeniach mobilnych z Androidem dzięki używaniu kanałów L2CAP zorientowanych na połączenie (CoC) w technologii Bluetooth Low Energy (BLE). CoC używa elastycznego bufora 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 w aparatach słuchowych kosztem opóźnienia.
Projekt CoC odnosi się do specyfikacji Bluetooth Core w wersji 5 (BT). Aby zachować zgodność z podstawowymi specyfikacjami, wszystkie wartości wielobajtowe na tej stronie muszą być odczytywane w formacie little-endian.
Terminologia
- centralny,
- Urządzenie z Androidem, które skanuje reklamy przez Bluetooth.
- urządzenie peryferyjne
- Aparat słuchowy, który wysyła pakiety reklamowe przez Bluetooth.
Topologia sieci i architektura systemu
W przypadku korzystania z CoC dla aparatów słuchowych topologia sieci zakłada jeden centralny i dwa urządzenia peryferyjne – jedno po lewej i jedno po prawej stronie, jak widać na rysunku 1. System audio Bluetooth traktuje lewe i prawe urządzenie peryferyjne jako jedno wyjście audio. Jeśli urządzenie peryferyjne jest niedostępne z powodu dopasowania do jednego ucha 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śli urządzenie centralne utraci połączenie z obydwoma urządzeniami peryferyjnymi, uzna, że połączenie z odbiornikiem dźwięku zostało przerwane. W takich przypadkach urządzenie centralne kieruje dźwięk do innego wyjścia.
Rysunek 1. Topologia parowania aparatów słuchowych z urządzeniami mobilnymi z Androidem za pomocą CoC przez BLE.
Jeśli urządzenie centralne nie przesyła strumieniowo danych audio do urządzenia peryferyjnego i może utrzymać połączenie BLE, nie powinno się odłączać 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 urządzeń słuchowych urządzenie centralne musi:
- Śledź ostatnio sparowane urządzenia peryferyjne po lewej i prawej stronie.
- Załóż, że urządzenia peryferyjne są używane, jeśli istnieje prawidłowe parowanie. Gdy połączenie zostanie utracone, urządzenie centralne musi spróbować połączyć się ponownie z sparowanym urządzeniem.
- Jeśli parowanie zostanie usunięte, przyjmij, że urządzenia peryferyjne nie są już używane.
W powyższych przypadkach parowanie odnosi się do zarejestrowania w systemie operacyjnym zestawu aparatów słuchowych z określonym identyfikatorem UUID i oznaczeniami lewego/prawego, a nie do procesu parowania Bluetooth.
Wymagania systemowe
Aby prawidłowo wdrożyć CoC i zapewnić użytkownikom wygodę, systemy Bluetooth w urządzeniach centralnym i peryferyjnym muszą:
- wdrożyć zgodny kontroler BT 4.2 lub nowszy; Zdecydowanie zalecamy korzystanie z LE Secure Connections.
- musi mieć centralny węzeł co najmniej 2 jednoczesne połączenia LE z parametrami opisanymi w formacie i czasie pakietu audio.
- urządzenie peryferyjne musi obsługiwać co najmniej 1 połączenie LE z parametrami opisanymi w sekcji Format i czas pakietu audio.
- musi mieć mechanizm kontroli przepływu oparty na kredytach LE [BT Vol 3, Part A, Sec 10.1]; Urządzenia muszą obsługiwać rozmiar MTU i MPS wynoszący co najmniej 167 bajtów w przypadku CoC i muszą być w stanie buforować do 8 pakietów.
- musi mieć rozszerzenie długości danych LE [BT Vol 6, Part B, Sec 5.1.9] z ładunkiem o długości co najmniej 167 bajtów.
-
urządzenie centralne musi obsługiwać polecenie HCI LE Connection Update Command i spełniać wymagania dotyczące parametrów
maximum_CE_Lengthiminimum_CE_Lengtho wartościach innych niż zero. - utrzymywać przepustowość danych dla 2 połączeń LE CoC z 2 różnymi urządzeniami peryferyjnymi z interwałami połączeń i rozmiarami ładunku w formacie pakietu audio i czasie.
-
urządzenie peryferyjne ustawia parametry
MaxRxOctetsiMaxRxTimew ramkachLL_LENGTH_REQlubLL_LENGTH_RSPna najmniejsze wymagane wartości, które są niezbędne w przypadku tych specyfikacji. Dzięki temu urządzenie centralne może optymalizować harmonogram czasowy podczas obliczania czasu potrzebnego na otrzymanie klatki.
Zdecydowanie zalecamy, aby urządzenie centralne i peryferyjne obsługiwały warstwę PHY 2 MB zgodnie ze specyfikacją BT 5.0. Urządzenie centralne musi obsługiwać połączenia audio o szybkości co najmniej 64 kbit/s w przypadku warstw PHY 1M i 2M. Nie można używać długiego zasięgu BLE PHY.
CoC wykorzystuje standardowe mechanizmy Bluetooth do szyfrowania warstwy łącza i przeskoku częstotliwości.
Usługi ASHA GATT
Urządzenie peryferyjne musi implementować usługę serwera GATT Audio Streaming for Hearing Aid (ASHA) opisaną poniżej. Urządzenie peryferyjne musi reklamować tę usługę w trybie ogólnej wykrywalności, aby urządzenie centralne mogło rozpoznać odbiornik audio. Wszystkie operacje przesyłania strumieniowego audio LE muszą wymagać szyfrowania. Strumieniowanie dźwięku przez BLE ma następujące cechy:
| Charakterystyka | Właściwości | Opis |
|---|---|---|
| ReadOnlyProperties | Przeczytaj | Zobacz ReadOnlyProperties. |
| AudioControlPoint | Zapisz i Zapisz bez odpowiedzi | Punkt kontrolny strumienia audio. Patrz AudioControlPoint. |
| AudioStatusPoint | Odczyt/powiadomienie | Pole raportu o stanie punktu kontroli dźwięku. Patrz AudioStatusPoint. |
| Głośność | Pisz bez odpowiedzi | Bajt z zakresu od -128 do 0 wskazujący poziom tłumienia, który ma być zastosowany do przesyłanego strumieniowo sygnału audio, w zakresie od -48 dB do 0 dB. Ustawienie -128 należy interpretować jako całkowite wyciszenie, czyli najniższy poziom głośności bez wyciszenia to -127, co odpowiada tłumieniu o -47,625 dB. Przy ustawieniu 0 przesyłany sygnał sinusoidalny o pełnej amplitudzie musi odpowiadać sygnałowi wejściowemu o poziomie 100 dB SPL w aparacie słuchowym. Urządzenie centralne musi przesyłać strumieniowo w nominalnej pełnej skali i używać tej zmiennej do ustawiania żądanego poziomu prezentacji na urządzeniu peryferyjnym. |
| LE_PSM_OUT | Przeczytaj | PSM używany do łączenia kanału audio. Wybierane z zakresu dynamicznego [BT Vol 3, Part A, Sec 4.22] |
Identyfikatory UUID przypisane do usługi i charakterystyk:
Identyfikator UUID usługi: {0xFDF0}
| Charakterystyka | UUID |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| AudioStatus | {38663f1a-e711-4cac-b641-326b56404837} |
| Głośność | {00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
| LE_PSM_OUT | {2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
Oprócz usługi ASHA GATT urządzenie peryferyjne musi też implementować usługę informacji o urządzeniu, aby urządzenie centralne mogło wykrywać nazwy producentów i nazwy urządzeń peryferyjnych.
ReadOnlyProperties
Właściwości ReadOnlyProperties mają te wartości:
| Bajt | Opis |
|---|---|
| 0 | Wersja – musi mieć wartość 0x01 |
| 1 | Patrz DeviceCapabilities. |
| 2-9 | Patrz HiSyncId. |
| 10 | Patrz FeatureMap. |
| 11-12 | RenderDelay. Jest to czas (w milisekundach) od momentu, w którym urządzenie peryferyjne odbiera ramkę audio, do momentu, w którym renderuje dane wyjściowe. Te bajty mogą służyć do opóźniania wideo w celu synchronizacji z dźwiękiem. |
| 13-14 | Zarezerwowany do użycia w przyszłości. Zainicjuj zerami. |
| 15-16 | Obsługiwane identyfikatory kodeków. Jest to maska bitowa identyfikatorów obsługiwanych kodeków. Wartość 1 w danym miejscu bitowym oznacza obsługiwany kodek. Na przykład wartość 0x0002 oznacza, że obsługiwany jest kodek G.722 przy częstotliwości 16 kHz. Wszystkie pozostałe bity muszą mieć wartość 0. |
DeviceCapabilities
| Bit | Opis |
|---|---|
| 0 | Strona urządzenia (0: lewa, 1: prawa) |
| 1 | Wskazuje, czy urządzenie jest samodzielne i odbiera dane mono, czy jest częścią zestawu (0: monofoniczne, 1: binauralne). |
| 2 | Urządzenie obsługuje CSIS (0: nieobsługiwane, 1: obsługiwane) |
| 3-7 | Zarezerwowany (ustawiony na 0) |
HiSyncID
To pole musi być unikalne dla wszystkich urządzeń binauralnych, ale musi być takie samo dla zestawu lewego i prawego.
| Bajt | Opis |
|---|---|
| 0-1 | Identyfikator producenta. Są to identyfikatory firmy przypisane przez BTSIG. |
| 2-7 | Unikalny identyfikator zestawu aparatów słuchowych. Ten identyfikator musi być taki sam na urządzeniu peryferyjnym po lewej i po prawej stronie. |
FeatureMap
| Bit | Opis |
|---|---|
| 0 | Obsługa strumieniowego przesyłania dźwięku LE CoC (tak/nie). |
| 1-7 | Zarezerwowane (ustawione na 0). |
Identyfikatory kodeków
Jeśli bit jest ustawiony, oznacza to, że dany kodek jest obsługiwany.
| ID / Numer bitu | Kodek i częstotliwość próbkowania | Wymagana szybkość transmisji | Czas renderowania klatki | Obowiązkowe w przypadku lokalizacji centralnej (C) lub peryferyjnej (P) |
|---|---|---|---|---|
| 0 | Zarezerwowany | Zarezerwowany | Zarezerwowany | Zarezerwowany |
| 1 | G.722 przy 16 kHz | 64 kb/s | Zmienna | C i P |
|
Numery 2–15 są zarezerwowane. 0 jest również zarezerwowany. |
||||
AudioControlPoint
Gdy LE CoC jest zamknięty, nie można używać tego punktu kontrolnego. Opis procedury znajdziesz w artykule Rozpoczynanie i zatrzymywanie strumienia audio.
| kod operacji, | Argumenty | Podprocedura GATT | Opis |
|---|---|---|---|
1 «Start» |
|
Zapisz odpowiedź i oczekuj dodatkowego powiadomienia o stanie za pomocą charakterystyki AudioStatusPoint. |
Instruuje urządzenie peryferyjne, aby zresetowało kodek i rozpoczęło odtwarzanie klatki 0. Pole kodeka wskazuje identyfikator kodeka, który ma być używany podczas odtwarzania.
Na przykład pole kodeka ma wartość „1” w przypadku kodeka G.722 przy częstotliwości 16 kHz. Pole bitowe typu audio wskazuje typy audio obecne w strumieniu:
Urządzenie peryferyjne nie może wysyłać próśb o aktualizację połączenia, dopóki nie otrzyma kodu operacji «Stop».
|
2 «Stop» |
Brak | Zapisz odpowiedź i oczekuj dodatkowego powiadomienia o stanie za pomocą charakterystyki AudioStatusPoint. | Instruuje urządzenie peryferyjne, aby przestało renderować dźwięk. Po zatrzymaniu odtwarzania należy zainicjować nową sekwencję konfiguracji dźwięku, aby ponownie go odtwarzać. |
3 «Status» |
|
Pisz bez odpowiedzi |
Informuje podłączone urządzenie peryferyjne o aktualizacji stanu innego urządzenia peryferyjnego. Połączone pole wskazuje typ aktualizacji:
|
AudioStatusPoint
Pole raportu o stanie punktu kontroli dźwięku
| kody operacji, | Opis |
|---|---|
| 0 | Stan: OK |
| -1 | Nieznane polecenie |
| -2 | Nieprawidłowe parametry |
Reklamy usługi ASHA GATT
Identyfikator UUID usługi musi znajdować się w pakiecie reklamowym. W ramce odpowiedzi reklamy lub skanowania urządzenia peryferyjne muszą mieć dane usługi:
| Przesunięcie bajtów | Nazwa | Opis |
|---|---|---|
| 0 | Długość reklamy | >= 0x09 |
| 1 | Typ reklamy | 0x16 (Service Data - 16-bits UUID) |
| 2–3 | Identyfikator UUID usługi |
0xFDF0 (little-endian) Uwaga: to jest tymczasowy identyfikator. |
| 4 | Wersja protokołu | 0x01 |
| 5 | Uprawnienie |
|
| 6-9 | Skrócony identyfikator HiSyncID | 4 najbardziej znaczące bajty parametru HiSyncId. Te bajty powinny być najbardziej losową częścią identyfikatora. |
Urządzenia peryferyjne muszą mieć typ danych Complete Local Name, który wskazuje nazwę aparatu słuchowego. Ta nazwa będzie używana w interfejsie urządzenia mobilnego, aby użytkownik mógł wybrać odpowiednie urządzenie. Nazwa nie może wskazywać lewego ani prawego kanału, ponieważ te informacje są podawane 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 oba typy danych („Complete Local Name” i „Service Data for ASHA service”) muszą występować w tej samej ramce. Dzięki temu skaner urządzenia mobilnego może uzyskać oba rodzaje danych w tym samym wyniku skanowania.
Podczas początkowego parowania ważne jest, aby urządzenia peryferyjne reklamowały się z częstotliwością wystarczającą do szybkiego wykrycia ich przez urządzenie mobilne i sparowania z nimi.
Synchronizowanie lewego i prawego urządzenia peryferyjnego
Aby współpracować z Bluetooth na urządzeniach mobilnych z Androidem, urządzenia peryferyjne muszą być zsynchronizowane. Odtwarzanie na lewym i prawym urządzeniu peryferyjnym musi być zsynchronizowane w czasie. Oba urządzenia peryferyjne muszą odtwarzać próbki dźwięku ze źródła w tym samym czasie.
Urządzenia peryferyjne mogą synchronizować czas, używając numeru sekwencyjnego dodanego do każdego pakietu ładunku audio. Urządzenie centralne 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 1 po każdym pakiecie audio. Każdy numer sekwencji ma 8 bitów, więc numery sekwencji będą się powtarzać po 256 pakietach audio. Ponieważ rozmiar każdego pakietu audio i częstotliwość próbkowania są stałe w przypadku każdego połączenia, oba urządzenia peryferyjne mogą określić względny czas odtwarzania. Więcej informacji o pakiecie audio znajdziesz w sekcji Format pakietu audio i czas.
Centrum pomaga, dostarczając wyzwalacze do urządzeń binauralnych, gdy może być potrzebna synchronizacja. Te wyzwalacze informują każde urządzenie peryferyjne o stanie sparowanego urządzenia peryferyjnego za każdym razem, gdy występuje operacja, która może wpłynąć na synchronizację. Aktywatory to:
-
W ramach polecenia
«Start»AudioControlPoint podawany jest bieżący stan połączenia drugiej strony urządzeń binauralnych. -
Za każdym razem, gdy na jednym urządzeniu peryferyjnym nastąpi połączenie, rozłączenie lub aktualizacja parametru połączenia, do drugiego urządzenia binauralnego wysyłane jest polecenie
«Status»z punktu kontroli dźwięku.
Format i synchronizacja pakietów audio
Pakowanie ramek audio (bloków próbek) w pakiety umożliwia aparatowi słuchowemu określanie czasu na podstawie punktów odniesienia warstwy łącza. Aby uprościć wdrożenie:
- Ramka audio powinna zawsze odpowiadać interwałowi połączenia w czasie. Jeśli np. interwał połączenia wynosi 20 ms, a częstotliwość próbkowania to 16 kHz, ramka audio musi 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 trwania ramki lub interwału połączenia.
- Przed ramkami audio musi znajdować się bajt sekwencji. Bajt sekwencji musi być liczony z zawijaniem i umożliwiać urządzeniu wykrywanie niezgodności bufora lub niedoboru.
-
Ramka audio musi zawsze mieścić się w jednym pakiecie LE. Ramka audio musi być wysyłana jako osobny pakiet L2CAP. Rozmiar jednostki LE LL PDU musi wynosić:
rozmiar ładunku audio + 1 (licznik sekwencji) + 6 (4 bity na nagłówek L2CAP, 2 bity na SDU) - Zdarzenie połączenia powinno być zawsze wystarczająco duże, aby zawierać 2 pakiety audio i 2 puste pakiety ACK, co pozwala zarezerwować przepustowość na retransmisje. Pamiętaj, że pakiet audio może być dzielony przez kontroler Bluetooth urządzenia centralnego. Urządzenie peryferyjne musi być w stanie odbierać więcej niż 2 fragmenty pakietów 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 odnosi się do Rec. ITU-T G.722 (09/2012) sekcja 1.4.4 „Multiplexer”
W przypadku wszystkich kodeków obsługiwanych przez urządzenie peryferyjne musi ono obsługiwać poniższe parametry połączenia. To niepełna lista konfiguracji, które może wdrożyć urządzenie centralne.
| Kodek | Szybkość transmisji bitów | Interwał połączenia | CE Length (1M/2M PHY) | Rozmiar ładunku audio |
|---|---|---|---|---|
| G.722 przy 16 kHz | 64 kb/s | 20 ms | 5000/3750 us | 160 bajtów |
Rozpoczynanie i zatrzymywanie strumienia audio
Przed rozpoczęciem strumienia audio urządzenie centralne wysyła zapytania do urządzeń peryferyjnych i ustala wspólny kodek. Konfiguracja strumienia przebiega w następującej kolejności:
- Odczytywane są wartości PSM i opcjonalnie RenderDelay. Te wartości mogą być przechowywane w pamięci podręcznej przez centralę.
- Otwarty jest kanał CoC L2CAP – urządzenie peryferyjne musi początkowo przyznać 8 kredytów.
- Wydawana jest aktualizacja połączenia, aby przełączyć link na parametry wymagane przez wybrany kodek. Centrala może przeprowadzić tę aktualizację połączenia przed połączeniem CoC w poprzednim kroku.
- Zarówno host centralny, jak i urządzenie peryferyjne czekają na zdarzenie zakończenia aktualizacji.
-
Uruchom ponownie koder dźwięku i zresetuj liczbę sekwencji pakietów do 0.
Na urządzeniu AudioControlPoint wydawane jest polecenie
«Start»z odpowiednimi parametrami. Urządzenie centralne czeka na powiadomienie o stanie«Start»z urządzenia peryferyjnego przed rozpoczęciem przesyłania strumieniowego. Dzięki temu urządzenie peryferyjne ma czas na przygotowanie potoku odtwarzania dźwięku. Podczas strumieniowania dźwięku replika powinna być dostępna przy każdym zdarzeniu połączenia, nawet jeśli bieżące opóźnienie repliki jest różne od zera. - Urządzenie peryferyjne pobiera pierwszy pakiet audio z wewnętrznej kolejki (numer sekwencyjny 0) i odtwarza go.
Centrum wydaje polecenie «Stop», aby zamknąć strumień audio. Po wykonaniu tego polecenia 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. Gdy urządzenie centralne nie przesyła strumieniowo dźwięku, powinno nadal utrzymywać połączenie LE na potrzeby usług GATT.
Urządzenie peryferyjne nie może wysyłać do urządzenia centralnego aktualizacji połączenia. Aby oszczędzać energię, urządzenie centralne może wysyłać do urządzenia peryferyjnego aktualizację połączenia, gdy nie przesyła strumieniowo dźwięku.