Aparaty słuchowe mogą mieć włączone lepsze ułatwienia dostępu Urządzenia mobilne z Androidem obsługujące technologię L2CAP zorientowaną na połączenie (CoC) przez Bluetooth Low Energy (BLE). CoC stosuje elastyczną z buforem kilku pakietów audio, by zapewnić stały przepływ dźwięku, nawet w przypadku utraty pakietów. Ten bufor zapewnia jakość dźwięku: aparatami słuchowymi kosztem opóźnień.
Konstrukcja CoC odwołuje się do Bluetooth Podstawowa specyfikacja: wersja 5 (BT). Aby zachować zgodność z podstawowymi specyfikacjami, wszystkie pliki wielobajtowe należy odczytywać jako little-endian.
Terminologia
- Central – urządzenie z Androidem, które skanuje pod kątem reklam przez Bluetooth.
- Urządzenie peryferyjne – aparat słuchowy, który wysyła dźwięk. przez Bluetooth.
Topologia sieci i architektura systemu
Podczas używania CoC z aparatami słuchowymi topologia sieci zakłada środkowe i 2 urządzenia peryferyjne, jedno lewe i jedno prawe, jak widać na ilustracji Rysunek 1. System audio Bluetooth widzi lewą stronę urządzenia peryferyjne i prawe urządzenia peryferyjne jako jeden odbiornik audio. Jeśli urządzenie peryferyjne z powodu dopasowania monotonnego lub utraty połączenia, środkowa miksuje lewy i prawy kanał audio oraz przesyła dźwięk. z pozostałym urządzeniem peryferyjnym. Jeśli centrala utraci połączenie z obydwoma urządzeniami urządzeń peryferyjnych, centrala weźmie pod uwagę połączenie z wyjściem audio zgubiony. W takich przypadkach centralny punkt wyjścia kieruje dźwięk do innego wyjścia.
Rysunek 1. Topologia parowania aparatów słuchowych
Urządzenia mobilne z Androidem używające CoC zamiast BLE
Gdy centrala nie przesyła danych audio do urządzenia peryferyjnego i może utrzymuj połączenie BLE, moduł centralny nie powinien odłączać się od urządzenia peryferyjnego. Utrzymanie połączenia umożliwia komunikację danych do serwera GATT działającego na urządzeniu peryferyjnym.
Podczas parowania i łączenia urządzeń słuchowych centralny powinien:
- Śledź najnowsze sparowane urządzenia peryferyjne (lewe i prawe).
- Załóżmy, że urządzenia peryferyjne są używane, jeśli istnieje prawidłowe sparowanie. centralny spróbuje połączyć się lub ponownie połączyć z sparowanymi na urządzeniu po utracie połączenia.
- Załóżmy, że po usunięciu parowania urządzenia peryferyjne nie są już używane.
W powyższych przypadkach parowanie odnosi się do działania rejestracji zestawu aparatów słuchowych z danym UUID, oznaczenia lewej/prawej strony w systemie operacyjnym, a nie w procesie parowania Bluetooth.
Wymagania systemowe
Aby prawidłowo zaimplementować kodowanie CoC dla wygody użytkowników, w urządzeniach centralnych i peryferyjnych powinny:
- zaimplementuj zgodny kontroler BT 4.2 lub nowszy. LE Secure Connections to zdecydowanie zalecane.
- muszą mieć centralną obsługę co najmniej 2 równoczesnych połączeń LE z parametrami opisane w sekcji Pakiet audio formatu i czasu.
- mieć obsługę urządzeń peryferyjnych z co najmniej 1 połączeniem LE z parametrami. opisane w sekcji Pakiet audio formatu i czasu.
- mieć kontrolę przepływu na podstawie udziału w konwersji [BT, część A, sek. 10.1]. Urządzenia powinny obsługiwać MTU i MPS o rozmiarze co najmniej 167 bajtów CoC i buforować do 8 pakietów.
- mają rozszerzenie długości danych LE [BT Vol 6, Part B, Sec 5.1.9] oraz ładunek o rozmiarze co najmniej 167 bajtów.
-
urządzenie centralne musi obsługiwać polecenie aktualizacji połączenia HCI LE.
i przestrzegać innych niż 0
maximum_CE_Lengthorazminimum_CE_Length. - zapewnia centralną utrzymanie przepustowości danych przez 2 połączenia LE CoC z dwoma różne urządzenia peryferyjne z częstotliwością połączeń i ładunkiem; rozmiary w pakietach audio formatu i czasu.
-
ustaw na urządzeniu peryferyjnym
MaxRxOctetsiLL_LENGTH_REQzawiera parametryMaxRxTimelubLL_LENGTH_RSPklatek, aby były jak najmniejszymi wymaganymi wartościami które są niezbędne dla tych specyfikacji. Dzięki temu system operacyjny zoptymalizować algorytm szeregowania przy obliczaniu ilości czasu potrzebne do otrzymania klatki.
Zdecydowanie zalecamy, aby centralny i peryferyjny system obsługiwał PHY o rozmiarze 2 MB jako wymienione w specyfikacji BT 5.0. Centrala będzie obsługiwać linki audio co najmniej 64 kb/s w przypadku 1 MB i 2 mln PHY. Nie należy używać PHY o dalekim zasięgu BLE.
CoC używa standardowych mechanizmów Bluetooth do szyfrowania w warstwie linków. i zmienianie częstotliwości.
Usługi ASHA GATT
Urządzenie peryferyjne powinno wdrożyć strumieniowe przesyłanie dźwięku z aparatu słuchowego (ASHA) Usługa serwera GATT opisana poniżej. Urządzenie peryferyjne musi rozgłaszać tę usługę w ogólnym trybie wykrywalności, aby umożliwić do centralnego rozpoznawania dźwięku. Dowolne operacje strumieniowania LE Audio wymaga szyfrowania. Strumieniowe przesyłanie dźwięku BLE składa się z następujące cechy:
| Cechy | Właściwości | Opis |
|---|---|---|
| Właściwości tylko do odczytu | Odczytane | Zobacz ReadOnlyWłaściwości. |
| Punkt sterowania dźwiękiem | Pisanie i pisanie bez odpowiedzi | Punkt kontrolny strumienia audio. Zobacz AudioControlPoint. |
| AudioStatusPoint | Przeczytaj/powiadom | Pole raportu o stanie punktu kontrolnego dźwięku. Zobacz AudioStatusPoint. |
| Głośność | Pisz bez odpowiedzi | Bajt z zakresu od -128 do 0 wskazujący stopień skupienia, do którego należy zastosować przesyłanego sygnału audio w zakresie od -48 dB do 0 dB. Ustawienie -128 powinno być interpretowane jako całkowicie wyciszony, tj.najniższy poziom głośności bez wyciszenia. poziom tłumienia wynosi -127, co odpowiada tłumieniu na poziomie -47,625 dB. Przy ustawieniu 0. przesłany sinus odpowiednik w aparacie słuchowym. Centralny strumień będzie nominalny pełnej skali i użyj tej zmiennej do ustawienia odpowiedniego poziomu prezentacji urządzenia peryferyjnego. |
| LE_PSM_OUT | Odczytane | PSM, który ma być używany do łączenia kanału audio. Do wyboru z listy zakres dynamiczny [BT, tom 3, część A, s. 4.22] |
Identyfikatory UUID przypisane do usługi i cech:
UUID usługi: {0xFDF0}
| Cechy | Identyfikator UUID |
|---|---|
| Właściwości tylko do odczytu | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| Punkt sterowania dźwiękiem | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| Stan dźwięku | {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ż zaimplementować usługę informacji o urządzeniu, aby umożliwić centralne wykrywanie nazwy producenta i nazwy urządzenia peryferyjnego.
Właściwości tylko do odczytu
ReadOnlyWłaściwości ma następujące wartości:
| B | Opis |
|---|---|
| 0 | Wersja – musi to być 0x01 |
| 1 | Zobacz DeviceCapabilities (Możliwości urządzenia). |
| 2-9 | Zobacz HiSyncId. |
| 10 | Zobacz FeatureMap |
| 11-12 | RenderOpóźnienie. Jest to czas (w milisekundach) od momentu urządzenie peryferyjne odbiera ramkę audio, dopóki nie wyrenderuje się dane wyjściowe. Te bajty mogą zostać wykorzystane do opóźnienia filmu synchronizować z dźwiękiem. |
| 13-14 | Zarezerwowany do użycia w przyszłości. Inicjowanie do zera. |
| 15-16 | Obsługiwane identyfikatory kodeków. To jest maska bitowa identyfikatorów obsługiwanych kodeków. Lokalizacja 1-bitowa odpowiada obsługiwane kodeka. Na przykład 0x0002 oznacza, że kod G.722 przy 16 kHz jest obsługiwane. Pozostałe bity powinny być ustawione na 0. |
Funkcje urządzenia
| Końcówka | Opis |
|---|---|
| 0 | Po stronie urządzenia (0: po lewej, 1: po prawej) |
| 1 | Wskazuje, czy urządzenie jest autonomiczne i odbiera dane mono, czy urządzenie należy do zestawu |
| 2 | Urządzenie obsługuje CSIS (0: nieobsługiwane, 1: obsługiwane) |
| 3-7 | Zarezerwowana (ustawiona na 0) |
Identyfikator HiSyncID
To pole musi być unikatowe dla wszystkich urządzeń binauralnych, ale musi być dla lewego i prawego zestawu.
| B | Opis |
|---|---|
| 0-1 | Identyfikator producenta. Jest to Firma Identyfikatory przypisane przez BTSIG. |
| 2-7 | Unikalny identyfikator identyfikujący zestaw aparatów słuchowych. Ten identyfikator musi być ustawiony po lewej i prawej stronie urządzenia peryferyjnego. |
Mapa funkcji
| Końcówka | Opis |
|---|---|
| 0 | Obsługa strumieniowania z wyjścia audio LE CoC (Tak/Nie). |
| 1-7 | Zarezerwowana (ustawiona na 0). |
Identyfikatory kodeków
Jeśli bit jest ustawiony, obsługiwany jest dany kodek.
| ID / numer bitu | Kodek i częstotliwość próbkowania | Wymagana szybkość transmisji bitów | Czas renderowania klatki | Obowiązkowe na centralnym (C) lub urządzeniu peryferyjnym (P) |
|---|---|---|---|---|
| 0 | Zarezerwowany | Zarezerwowany | Zarezerwowany | Zarezerwowany |
| 1 | G.722 przy 16 kHz | 64 kb/s | Zmienna | C i P |
|
Zarezerwowano od 2 do 15. Wartość 0 też jest zarezerwowana. |
||||
Punkt sterowania dźwiękiem
Tego punktu kontrolnego nie można używać, gdy LE CoC jest zamknięty. Zobacz Początki zatrzymania strumienia audio w opisie procedury.
| Kod operacji | Argumenty | Podprocedura GATT | Opis |
|---|---|---|---|
1 «Start» |
|
Pisz z odpowiedziami i spodziewaj się dodatkowego powiadomienia o stanie za pomocą Cechy AudioStatusPoint. |
Nakazuje na urządzeniu peryferyjnym zresetowanie kodeka i uruchomienie
odtworzenie klatki 0. Pole kodeka wskazuje identyfikator kodeka, który ma być używany
do tego odtwarzania.
np. pole kodeka to „1”. dla G.722 przy 16 kHz. Pole bitu typu audio wskazuje dostępne typy audio w strumieniu:
Urządzenie peryferyjne nie będzie żądać aktualizacji połączenia przed Odebrano kod operacji «Stop».
|
2 «Stop» |
Brak | Pisz z odpowiedziami i spodziewaj się dodatkowego powiadomienia o stanie za pomocą Cechy AudioStatusPoint. | Powoduje zatrzymanie renderowania dźwięku na urządzeniu peryferyjnym. Nowy dźwięk sekwencję konfiguracji należy zainicjować po tym przystanku aby ponownie wyrenderować dźwięk. |
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 o stanie punktu kontrolnego dźwięku
| Kody operacji | Opis |
|---|---|
| 0 | Stan: OK |
| -1 | Nieznane polecenie |
| -2 | Niedozwolone parametry |
Reklamy usługi ASHA GATT
UUID usługi musi znajdować się w pakietu reklamowego. W reklamie lub skanie ramce odpowiedzi, urządzenia peryferyjne muszą mieć dane usługi:
| Przesunięcie bajtów | Nazwa | Opis |
|---|---|---|
| 0 | Długość reklamy | >= 0 x 09 |
| 1 | Typ reklamy | 0x16 (dane usługi – 16-bitowy UUID) |
| 2–3 | UUID usługi |
0xFDF0 (little-endian) Uwaga: jest to identyfikator tymczasowy. |
| 4 | Wersja protokołu | 0x01 |
| 5 | Funkcja |
|
| 6-9 | Skrócony HiSyncID | Cztery najważniejsze bajty HiSyncId. Te bajty powinny być najbardziej losową częścią identyfikatora. |
Urządzenia peryferyjne muszą mieć pełną nazwę lokalną. typ danych, który wskazuje nazwę aparatu słuchowego. Ta nazwa będzie być używany w interfejsie urządzenia mobilnego, aby użytkownik mógł wybrać, odpowiednie urządzenie. Nazwa nie może wskazywać lewej ani prawej strony. kanału, ponieważ te informacje znajdują się w DeviceCapabilities (Możliwości urządzenia).
Jeśli urządzenia peryferyjne umieszczają nazwę i typy danych usługi ASHA w tym samym typu ramki (ADV lub SCAN RESP), a następnie 2 typy danych („Complete Local Name” (Pełna nazwa lokalna) i „Dane usługi dla usługi ASHA”) będą w tym samym kadrze. Dzięki temu skaner urządzenia mobilnego może pobrać oba dane w ramach tego samego wyniku skanowania.
Podczas pierwszego parowania należy upewnić się, że urządzenia peryferyjne wyświetlać reklamy z wystarczającą szybkością, by urządzenie mobilne mogło je wyświetlać wykryć urządzenia peryferyjne i utworzyć z nimi powiązanie.
Synchronizuj lewe i prawe urządzenia peryferyjne
Korzystanie z Bluetootha na urządzeniach mobilnych z Androidem i urządzeniach peryferyjnych są odpowiedzialne za ich synchronizację. Odtwarzanie urządzenia peryferyjne z lewej i prawej strony muszą być obecnie się znajdujesz. Oba urządzenia peryferyjne muszą odtwarzać próbki audio z w tym samym czasie.
Urządzenia peryferyjne mogą synchronizować czas przy użyciu sekwencji do każdego pakietu ładunku audio. Centralny gwarantuje, że pakiety audio, które powinny być odtwarzane w tym samym czasie, czas na każdym urządzeniu peryferyjnym ma ten sam numer sekwencyjny. Sekwencja zwiększa się o jeden po każdym pakiecie audio. Każda sekwencja liczba jest 8-bitowa, więc numery w sekwencji powtórz się po 256 pakietów audio. Ponieważ rozmiar pakietu audio i częstotliwość próbkowania są stałe dla każdego połączenia oba urządzenia peryferyjne mogą wydedukować dane względne w czasie rzeczywistym. Więcej informacji o pakiecie audio znajdziesz w artykule Format pakietów audio .
Wspomaga to, przekazując wyzwalacze do urządzeń binauralnych podczas synchronizacji może być konieczne. Te wyzwalacze informują każde urządzenie peryferyjne o stanie jego sparowanego urządzenia peryferyjnego, gdy wykonywana jest operacja może mieć wpływ na synchronizację. Czynniki uruchamiające:
-
W ramach polecenia
«Start»w programie AudioControlPoint bieżący stan połączenia drugiej strony zestawu binarnego urządzeń. -
zawsze, gdy nawiązywane jest połączenie, rozłączenie lub
operacji aktualizacji parametrów połączenia na jednym urządzeniu peryferyjnym,
polecenie
«Status»w programie AudioControlPoint jest wysyłane do po drugiej stronie urządzenia binauralnego.
Format i czas trwania pakietu audio
Pakowanie ramek audio (bloków próbek) w pakietach sprawia, że słuch instrument otrzymuje czas z kotwicy czasowych warstwy linku. Do uprość implementację:
- Ramka audio powinna zawsze odpowiadać interwałowi połączenia w czasie. Jeśli na przykład interwał połączenia wynosi 20 ms, a częstotliwość próbkowania jest 16 kHz, wówczas ramka audio powinna zawierać 320 próbek.
- Częstotliwość próbkowania w systemie jest ograniczona do wielokrotności 8 kHz do zawsze mają całkowitą liczbę próbek w ramce, niezależnie od czas renderowania klatki lub interwał połączenia.
- Do bajtów sekwencji dołączane są klatki audio. Bajt sekwencji będzie liczyć zawinięcie i umożliwić urządzeniu peryferyjnego wykrywania niedopasowania bufora lub niedostatecznego przepływu.
-
Ramka audio powinna zawsze mieścić się w jednym pakiecie LE. Dźwięk
powinna być wysyłana jako osobny pakiet L2CAP. Rozmiar LE
LL PDU to:
rozmiar ładunku audio + 1 (licznik sekwencji) + 6 (4 – nagłówek L2CAP, 2 – SDU) - Zdarzenie połączenia powinno zawsze być na tyle duże, by mogło zawierać 2 pliki audio i 2 puste pakiety na potrzeby potwierdzenia, by zarezerwować przepustowość i ponownym przesyłaniu danych. Pamiętaj, że pakiet audio może być pofragmentowany przez na kontrolerze Bluetooth w centralnym kontrolerze. Urządzenie peryferyjne musi mieć możliwość odbierania więcej niż 2 pofragmentowane pakiety audio na zdarzenie połączenia.
Aby zapewnić pewną elastyczność, długość pakietów G.722 określone dane. Długość pakietu G.722 może się zmieniać w zależności od połączenia interwał wyznaczany przez środek.
Format wyjściowy G.722 odwołuje się do Zalec. ITU-T G.722 (09.2012) sekcji 1.4.4 „multiplekser”
W przypadku wszystkich kodeków obsługiwanych przez urządzenie peryferyjne obsługuje poniższe parametry połączenia. Powyższa lista nie jest wyczerpująca konfiguracji, które może wdrożyć centrala.
| Kodek | Szybkość transmisji bitów | Interwał połączenia | Długość CE (1 M/2 mln PHY) | Rozmiar ładunku audio |
|---|---|---|---|---|
| G.722 przy 16 kHz | 64 kb/s | 20 ms | 5000/3750 USA | 160 bajtów |
Rozpoczynanie i zatrzymywanie strumienia audio
Przed uruchomieniem strumienia audio centrala wysyła zapytania do urządzeń peryferyjnych i ustanawia kodek typu „wspólny mianownik”. Strumień Proces konfiguracji przebiega w następujący sposób:
- PSM i opcjonalnie funkcja RenderDelay są odczytywane. Wartości te które mogą być buforowane przez system centralny.
- Otwarty jest kanał CoC L2CAP – urządzenie peryferyjne przyzna 8 punktów od początku.
- Połączenie zostanie zaktualizowane, aby przełączyć połączenie na parametry. wymaganych przez wybrany kodek. Centrum może zaktualizować informacje o połączeniu przed połączeniem CoC w poprzednim kroku.
- Host centralny i peryferyjny czekają na aktualizację pełne zdarzenie.
-
Uruchom ponownie koder audio i zresetuj liczbę pakietów do 0.
Polecenie
«Start»z odpowiednimi parametrami jest przyznawany w narzędziu AudioControlPoint. Centrala czeka na pomyślne powiadomienie o stanie poprzedniego polecenia«Start»z urządzenia peryferyjnego. Takie oczekiwanie przekazuje czas na przygotowanie potoku odtwarzania dźwięku. Podczas strumieniowego przesyłania dźwięku replika powinny być dostępne przy każdym zdarzeniu połączenia, mimo że bieżący Opóźnienie repliki może nie wynosić zero. - Urządzenie peryferyjne pobiera pierwszy pakiet audio z wewnętrznej kolejki. (numer sekwencji 0) i zostanie odtworzony.
W środku uruchamia się polecenie «Stop», które zamyka strumienia audio. Po tym poleceniu urządzenie peryferyjne nie musi być dostępne w każdym zdarzenie połączenia. Aby ponownie uruchomić strumieniowanie dźwięku, wykonaj powyższe czynności, zaczynając od od kroku 5. Gdy pojemnik centralny nie jest strumieniowania dźwięku, powinien wciąż utrzymywać połączenie LE dla GATT. usług Google.
Urządzenie peryferyjne nie powinno przesłać aktualizacji połączenia z centralą. Aby oszczędzać energię, centrala może zaktualizować połączenie do urządzenia peryferyjnego, gdy nie przesyła ono strumieniowo dźwięku.