Urządzenia wspomagające słuch (HA) mogą mieć ulepszone funkcje ułatwień dostępu na urządzeniach mobilnych z Androidem, korzystając z kanałów L2CAP (orientowanych na połączenie) w technologii Bluetooth Low Energy (BLE). CoC używa elastycznego bufora z kilkoma pakietami 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 specyfikacji Bluetooth Core w wersji 5 (BT). Aby zachować zgodność ze specyfikacjami podstawowymi, wszystkie wartości wielobajtowe na tej stronie należy odczytać w postaci 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 w przypadku aparatów słuchowych topologia sieci zakłada jedno urządzenie centralne i 2 peryferyjne (po jednym po lewej i po prawej stronie), jak pokazano na rysunku 1. System audio Bluetooth traktuje lewe i prawe urządzenia peryferyjne jako pojedynczy odbiornik audio. Jeśli urządzenie peryferyjne jest niedostępne z powodu mono lub utraty połączenia, urządzenie centralne łączy lewy i prawy kanał audio oraz przesyła dźwięk do pozostałych urządzeń peryferyjnych. Jeśli centrala utraci połączenie z obu urządzeniami peryferyjnymi, uzna, że połączenie z urządzeniem 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 Androidem za pomocą CoC przez BLE
Gdy centrala nie przesyła strumieniowo danych audio do urządzenia peryferyjnego i może utrzymywać połączenie BLE, nie powinna się odłączać od tego urządzenia. Utrzymanie połączenia umożliwia przesyłanie danych do serwera GATT znajdującego się na urządzeniu peryferyjnym.
Podczas parowania i podłączania urządzeń słuchowych centrala:
- śledzić ostatnio sparowane urządzenia peryferyjne po lewej i po prawej stronie;
- Zakładaj, że urządzenia peryferyjne są używane, jeśli istnieje prawidłowe parowanie. Gdy połączenie zostanie utracone, centrala będzie próbować połączyć się z sparowanym urządzeniem lub nawiązać z nim połączenie ponownie.
- Zakładamy, że urządzenia peryferyjne nie są już używane, jeśli parowanie zostało usunięte.
W wymienionych powyżej przypadkach parowanie odnosi się do rejestrowania zestawu aparatów słuchowych z danym identyfikatorem UUID i oznaczeniem lewy/prawy w systemie operacyjnym, a nie do procesu parowania Bluetooth.
Wymagania systemowe
Aby prawidłowo wdrożyć CoC i zapewnić użytkownikom dobre wrażenia, systemy Bluetooth w urządzeniach centralnych i peryferyjnych muszą:
- wdrożyć zgodny kontroler BT w wersji 4.2 lub nowszej. Zdecydowanie zalecamy korzystanie z bezpiecznych połączeń LE.
- centralny obsługujący co najmniej 2 jednoczesne łącza LE z parametrami opisanymi w sekcji Format i synchronizacja pakietów audio;
- urządzenia peryferyjne obsługują co najmniej 1 połączenie LE z parametrami opisanymi w Format i czas trwania pakietu audio.
- mieć kontrolę przepływu na podstawie kredytu 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 oraz muszą być w stanie buforować do 8 pakietów.
- 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 aktualizacji połączenia LE HCI i spełniać wymagania dotyczące niezerowych parametrów
maximum_CE_Lengthiminimum_CE_Length; - centrala musi utrzymywać przepustowość danych dla 2 połączeń LE CoC z 2 różnymi urządzeniami peryferyjnymi z uwzględnieniem interwałów połączenia i rozmiarów pakietów danych w formacie i zgodnie z harmonogramem pakietów audio.
-
urządzenie peryferyjne ustawia parametry
MaxRxOctetsiMaxRxTimew ramkachLL_LENGTH_REQlubLL_LENGTH_RSPna najmniejsze wymagane wartości, które są niezbędne do obsługi tych specyfikacji. Umożliwia to centralnemu harmonogramowi czasu optymalizację przy obliczaniu czasu potrzebnego na otrzymanie klatki.
Zaleca się, aby urządzenie centralne i peryferyjne obsługiwało interfejs PHY 2 MB zgodnie ze specyfikacją BT 5.0. Centrala musi obsługiwać łącza audio o szybkości co najmniej 64 kbit/s w przypadku PHY 1 M i 2 M. Nie należy używać PHY BLE o długim zasięgu.
CoC używa standardowych mechanizmów Bluetooth do szyfrowania warstwy łącza i skoku 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 ogólnym trybie wykrywania, aby umożliwić urządzeniu centralnemu rozpoznanie odbiornika audio. Wszystkie operacje strumieniowego przesyłania dźwięku LE wymagają szyfrowania. Strumieniowe przesyłanie dźwięku przez BLE ma następujące cechy:
| Cecha | Właściwości | Opis |
|---|---|---|
| ReadOnlyProperties | Przeczytaj | Zobacz Właściwości tylko do odczytu. |
| AudioControlPoint | Write i Write without Response | Punkt kontrolny strumienia audio. Zobacz AudioControlPoint. |
| AudioStatusPoint | Odczyt/powiadomienie | Pole raportu stanu punktu sterowania dźwiękiem. Patrz AudioStatusPoint. |
| Głośność | Write without Response | Bajt w zakresie od -128 do 0 określający stopień tłumienia, który ma zostać zastosowany do strumieniowanego 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 -47,625 dB. W przypadku ustawienia 0 strumień tonów sinusoidalnych od szyny do szyny musi odpowiadać wejściu o 100 dBSPL w urządzeniu słuchowym. Centrala będzie przesyłać strumień w nominalnej pełnej skali i używać tej zmiennej do ustawiania żądanego poziomu prezentacji w peryferyjnym. |
| LE_PSM_OUT | Przeczytaj | PSM używany do łączenia kanału audio. Dobierane z zakresu dynamicznego [BT Vol 3, Part A, Sec 4.22] |
Identyfikatory UUID przypisane do usługi i jej cech:
Identyfikator UUID usługi: {0xFDF0}
| Cecha | 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 również implementować usługę informacji o urządzeniu, aby umożliwić urządzeniu centralnemu wykrywanie nazw producenta i urządzenia peryferyjnego.
ReadOnlyProperties
Właściwości ReadOnlyProperties mają te wartości:
| Bajt | Opis |
|---|---|
| 0 | Wersja – musi być równa 0x01. |
| 1 | Patrz DeviceCapabilities. |
| 2-9 | Patrz HiSyncId. |
| 10 | Zobacz FeatureMap. |
| 11-12 | RenderDelay. Czas w milisekundach od momentu, gdy urządzenie peryferyjne odbierze ramkę audio, do momentu wyrenderowania danych wyjściowych. Te bajty mogą służyć do opóźniania filmu w celu zsynchronizowania go z dźwiękiem. |
| 13-14 | Zarezerwowany do użycia w przyszłości. inicjować na 0; |
| 15-16 | Obsługiwane identyfikatory kodeków. Jest to maska bitowa obsługiwanych identyfikatorów kodeków. Wartość 1 w pozycji bitowej odpowiada obsługiwanemu kodekowi. Na przykład 0x0002 wskazuje, że kodek G.722 przy częstotliwości 16 kHz jest obsługiwany. Wszystkie pozostałe bity mają 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: mono, 1: stereo). |
| 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ń binaural, ale musi być takie samo w przypadku lewego i prawego zestawu.
| Bajt | Opis |
|---|---|
| 0-1 | Identyfikator producenta. Jest to identyfikator firmy przypisany przez BTSIG. |
| 2-7 | Unikalny identyfikator identyfikujący zestaw aparatów słuchowych. Ten identyfikator musi być taki sam w przypadku lewego i prawego urządzenia peryferyjnego. |
FeatureMap
| Bit | Opis |
|---|---|
| 0 | Obsługiwanie strumieniowego przesyłania wyjścia audio LE CoC (Tak/Nie). |
| 1-7 | Zarezerwowane (ustaw 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 bitów | Czas renderowania klatki | Wymagany w centralnym (C) lub peryferyjnym (P) |
|---|---|---|---|---|
| 0 | Zarezerwowany | Zarezerwowany | Zarezerwowany | Zarezerwowany |
| 1 | G.722 @ 16 kHz | 64 kbit/s | Zmienna | C i P |
|
Numery 2–15 są zarezerwowane. 0 jest również zarezerwowany. |
||||
AudioControlPoint
Nie można używać tego punktu kontrolnego, gdy łańcuch zaufania LE jest zamknięty. Aby dowiedzieć się, jak to zrobić, zapoznaj się z artykułem Rozpoczynanie i zatrzymywanie strumienia audio.
| Kod operacji | Argumenty | Procedura GATT | Opis |
|---|---|---|---|
1 «Start» |
|
Napisz z odpowiedzią, a otrzymasz dodatkową informację o stanie za pomocą charakterystyki AudioStatusPoint. |
Instrukcja dla urządzenia peryferyjnego, aby zresetować kodek i rozpocząć odtwarzanie ramki 0. Pole kodek wskazuje identyfikator kodeka, którego należy użyć do odtwarzania.
Na przykład pole kodeka ma wartość „1” w przypadku G.722 przy 16 kHz. Pole bitowe typu audio wskazuje typy audio występujące w strumieniu:
Urządzenie peryferyjne nie może prosić o aktualizacje połączenia, dopóki nie otrzyma kodu operacji «Stop».
|
2 «Stop» |
Brak | Napisz z odpowiedzią, a otrzymasz dodatkową informację o stanie za pomocą charakterystyki AudioStatusPoint. | Instrukcja dla urządzenia peryferyjnego, aby zatrzymało renderowanie dźwięku. Po zatrzymaniu należy rozpocząć nową sekwencję konfiguracji dźwięku, aby ponownie go wyrenderować. |
3 «Status» |
|
Pisanie bez odpowiedzi |
Informuje połączone urządzenie peryferyjne o aktualizacji stanu innego urządzenia peryferyjnego. Połączone pole wskazuje typ aktualizacji:
|
AudioStatusPoint
Pole raportu stanu punktu sterowania dźwiękiem
| Kody operacji | Opis |
|---|---|
| 0 | Stan OK |
| -1 | Nieznane polecenie |
| -2 | Nieprawidłowe parametry |
Reklamy usługi GATT ASHA
Identyfikator UUID usługi musi znajdować się w pakiecie reklamy. W ramce 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 (dane usługi – UUID 16-bitowy) |
| 2–3 | Identyfikator UUID usługi |
0xFDF0 (little-endian) Uwaga: to jest tymczasowy identyfikator. |
| 4 | Wersja protokołu | 0x01 |
| 5 | Funkcja |
|
| 6-9 | Obcięty HiSyncID | 4 najbardziej znaczące bajty identyfikatora 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 urządzenia mobilnego, aby użytkownik mógł wybrać właściwe urządzenie. Nazwa nie powinna wskazywać, czy jest to lewy czy prawy kanał, 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), te dwa typy danych („Pełna nazwa lokalna” i „Dane usługi dla usługi ASHA”) powinny pojawiać się w tym samym okienku. 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 wystarczającą szybkością, aby urządzenie mobilne mogło szybko je wykryć i z nimi nawiązać połączenie.
Synchronizacja urządzeń peryferyjnych po lewej i po prawej stronie
Aby korzystać 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 z tego samego źródła w tym samym czasie.
Urządzenia peryferyjne mogą synchronizować czas za pomocą sekwencyjnego numeru dodawanego do każdego pakietu danych audio. Urządzenie centralne zapewnia, że pakiety audio, które mają być odtwarzane w tym samym czasie na każdym z urządzeń peryferyjnych, mają ten sam numer sekwencji. Numer sekwencji 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ć co 256 pakietów audio. Ponieważ rozmiar pakietu audio i częstotliwość próbkowania są stałe w przypadku każdego połączenia, oba urządzenia peryferyjne mogą określić czas odtwarzania. Więcej informacji o pakietach audio znajdziesz w sekcji Format i synchronizacja pakietów audio.
Urządzenie centralne pomaga, przekazując urządzenia binauralne sygnały sterujące, gdy może być potrzebna synchronizacja. Te wyzwalacze informują każde urządzenie peryferyjne o stanie sparowanego urządzenia peryferyjnego, gdy tylko wystąpi operacja, która może wpłynąć na synchronizację. Aktywatory:
-
W ramach polecenia
«Start»usługi AudioControlPoint podany jest bieżący stan połączenia drugiej strony urządzeń binaural. -
Za każdym razem, gdy na jednym z peryferyjnych urządzeń nastąpi połączenie, rozłączenie lub operacja aktualizacji parametrów połączenia, polecenie
«Status»z AudioControlPoint zostanie wysłane do drugiej strony urządzeń binauralnych.
Format i synchronizacja pakietów audio
Pakowanie ramek audio (bloków próbek) do pakietów pozwala instrumentowi do analizy dźwięku określać czas na podstawie punktów odniesienia czasu warstwy łącza. Aby uprościć implementację:
- Ramka audio powinna zawsze pasować do interwału połączenia. Jeśli na przykład interwał połączenia wynosi 20 ms, a częstotliwość próbkowania to 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ć w ramce pewną liczbę próbek niezależnie od czasu klatki lub interwału połączenia.
- Bajt sekwencji musi poprzedzać ramki audio. Bajt sekwencji musi być zliczany z przewijaniem i umożliwiać urządzeniu peryferyjnemu wykrywanie niezgodności bufora lub przepełnienia.
-
Ramka audio musi zawsze mieścić się w pojedynczym pakiecie LE. Ramka audio powinna być wysyłana jako osobny pakiet L2CAP. Rozmiar PDU LL LE:
rozmiar ładunku audio + 1 (licznik sekwencji) + 6 (4 dla nagłówka L2CAP, 2 dla SDU) - Zdarzenie połączenia powinno być wystarczająco duże, aby zawierać 2 pakiety audio i 2 puste pakiety dla potwierdzenia odbioru, które rezerwuje przepustowość na potrzeby retransmisji. Pamiętaj, że pakiet audio może zostać podzielony przez kontroler Bluetooth w centrali. Urządzenie peryferyjne musi mieć możliwość odbierania więcej niż 2 rozbitych pakietów audio na zdarzenie połączenia.
Aby zapewnić centrali większą 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 ustawianego przez centralę.
Format oktetów wyjściowych G.722 odwołuje się do Rec. ITU-T G.722 (09/2012) sekcja 1.4.4 „Multiplexer”
W przypadku wszystkich obsługiwanych kodeków urządzenie peryferyjne musi obsługiwać te parametry połączenia: Oto niepełna lista konfiguracji, które może zaimplementować centrala.
| Kodek | Szybkość transmisji bitów | Interwał połączenia | Długość CE (1 M/2 M PHY) | Rozmiar ładunku audio |
|---|---|---|---|---|
| G.722 @ 16 kHz | 64 kbit/s | 20 ms | 5000/3750 µs | 160 bajtów |
Uruchamianie i zatrzymywanie strumienia audio
Przed rozpoczęciem strumienia audio urządzenie centralne wysyła zapytania do urządzeń peryferyjnych i ustala wspólny kodeki. Następnie konfiguracja strumienia przebiega zgodnie z tą sekwencją:
- PSM i opcjonalnie RenderDelay są odczytywane. Te wartości mogą być przechowywane w pamięci podręcznej przez centralę.
- Otwarto kanał CoC L2CAP – urządzenie peryferyjne przyzna 8 punktów na początek.
- Aby przełączyć połączenie na parametry wymagane dla wybranego kodeka, wysyłana jest aktualizacja połączenia. Centrala może przeprowadzić tę aktualizację połączenia przed połączeniem z kontenerem w poprzednim kroku.
- Zarówno host centralny, jak i peryferyjny oczekują na zdarzenie zakończenia aktualizacji.
-
Uruchom ponownie koder audio i zresetuj liczbę sekwencji pakietów do 0.
Na interfejsie AudioControlPoint wysyłane jest polecenie
«Start»z odpowiednimi parametrami. Przed rozpoczęciem przesyłania strumienia urządzenie centralne oczekuje na powiadomienie o udanym wykonaniu poprzedniego polecenia«Start»przez urządzenie peryferyjne. Ten czas oczekiwania daje urządzeniu peryferyjnemu czas na przygotowanie ścieżki odtwarzania dźwięku. Podczas strumieniowego przesyłania audio replika powinna być dostępna w przypadku każdego zdarzenia połączenia, mimo że bieżące opóźnienie repliki może być niezerowe. - Urządzenie peryferyjne pobiera pierwszy pakiet audio z wewnętrznej kolejki (numer sekwencji 0) i odtwarza go.
Centrala wysyła polecenie «Stop», aby zamknąć strumień audio. Po wykonaniu tego polecenia urządzenie peryferyjne nie musi być dostępne w przypadku każdego zdarzenia połączenia. Aby wznowić strumieniowanie dźwięku, wykonaj powyższą sekwencję, zaczynając od kroku 5. Gdy centrala nie przesyła strumieniowo dźwięku, nadal powinna utrzymywać połączenie LE w celu obsługi usług GATT.
Urządzenie peryferyjne nie może wysyłać do centrali informacji o zmianie stanu połączenia. Aby oszczędzać energię, jednostka centralna może wysłać aktualizację połączenia do urządzenia peryferyjnego, gdy nie przesyła ono strumieniowo dźwięku.