Dźwięk Bluetooth Low Energy

Bluetooth Low Energy Audio (LEA) zapewnia użytkownikom wysoką jakość dźwięku bez uszczerbku dla żywotności baterii i umożliwia płynne przełączanie się między różnymi przypadkami użycia. Android 13 (poziom 33 interfejsu API) ma wbudowaną obsługę LEA.

Większość zestawów słuchawkowych LEA będzie działać w trybie podwójnym, dopóki nie wzrośnie udział w rynku urządzeń źródłowych LEA. Użytkownicy powinni mieć możliwość sparowania i skonfigurowania obu trybów transmisji na słuchawkach z dwoma trybami.

Przypadki użycia

Integracja z LEA może być przydatna w tych przypadkach:

  • Udostępnianie dźwięku: użytkownicy mogą jednocześnie udostępniać wiele strumieni audio na 1 lub więcej urządzeń wyjściowych audio. Dźwięk jest synchronizowany między urządzeniem źródłowym a połączonymi urządzeniami.

  • Przesyłanie dźwięku: użytkownicy mogą przesyłać dźwięk do znajomych i rodziny, a także łączyć się z publicznymi transmisjami w celu uzyskania informacji, rozrywki lub ułatwień dostępu.

  • Obsługa kodeka audio LC3: jest to domyślny kodek audio, który zastępuje kodek SBC używany w profilu A2DP (media) i kodek mSBC w profilu HFP (głos). LC3 jest bardziej wydajny, można go ponownie skonfigurować i zapewnia wyższą jakość.

  • Ulepszone próbkowanie dźwięku: zestawy słuchawkowe mogą zachować wysoką jakość dźwięku wyjściowego podczas korzystania z mikrofonów. Bluetooth Classic obniża jakość dźwięku podczas korzystania z mikrofonów Bluetooth. W przypadku BLE Audio częstotliwość próbkowania wejścia i wyjścia może osiągnąć 32 kHz.

  • Mikrofon stereo: słuchawki douszne mogą nagrywać dźwięk za pomocą mikrofonów stereo, aby poprawić dźwięk przestrzenny.

  • Obsługa profilu aparatu słuchowego (HAP): HAP zapewnia użytkownikom większą dostępność i wygodę niż poprzednie protokoły ASHA. Użytkownicy mogą używać aparatów słuchowych do rozmów telefonicznych i aplikacji VoIP.

  • Obsługa protokołu Enhanced Attribute (EATT): EATT umożliwia deweloperom wysyłanie wielu poleceń jednocześnie do sparowanych słuchawek.

Kluczowe scenariusze

Wyróżniamy 4 główne kategorie przypadków użycia:

  1. Konwersacyjne: aplikacje Telefon i VoIP, które wymagają routingu komunikacji o niskim opóźnieniu, oferują wysoką jakość dźwięku i mniejsze wykorzystanie baterii.

  2. Gry: jednoczesne korzystanie z mikrofonu i odtwarzanie dźwięku w wysokiej jakości umożliwia przesyłanie dźwięku w wysokiej jakości do słuchawek. Gra mobilna może uzyskać dostęp do wejścia audio BLE, gdy gra uzna mikrofon Bluetooth za gotowy do użycia. Gdy gracz rozpocznie rozmowę na żywo z innym graczem, aplikacja gry może od razu użyć danych z mikrofonu.

  3. Multimedia: aplikacje multimedialne mogą ustawiać preferowane urządzenie menedżera dźwięku. Użytkownik może zastąpić to ustawienie, zmieniając preferowane urządzenie w ustawieniach systemu.

  4. Ułatwienia dostępu: aparaty słuchowe obsługujące BLE Audio mogą teraz korzystać z mikrofonu, co pozwala użytkownikom na ciągłe używanie aparatów słuchowych podczas rozmowy.

Interfejsy API i metody BLE Audio

Aby obsługiwać urządzenia audio BLE, wymagane są te interfejsy API i metody:

AudioManager

  • setCommunicationDevice() wybiera urządzenie audio, które ma być używane w przypadku komunikacji, np. podczas rozmów głosowych lub wideo. Ta metoda może być używana przez aplikacje do czatu głosowego lub wideo do wyboru innego urządzenia audio niż to, które jest domyślnie wybrane przez platformę. Ten interfejs API zastępuje te wycofane interfejsy API:startBluetoothSco(),stopBluetoothSco() i setSpeakerphoneOn().
  • clearCommunicationDevice() jest wywoływana po zakończeniu połączenia lub sesji w aplikacji, aby zapewnić użytkownikowi wygodę podczas przechodzenia między różnymi aplikacjami.

BluetoothProfile

Telecom InCallService

Telecom CallControl

Informacje o urządzeniu audio

  • AudioDeviceInfo.TYPE_BLE_HEADSET określa typ urządzenia audio jako urządzenie LEA. Służy do określania, czy urządzenie słuchowe jest urządzeniem LEA.

Rejestrator dźwięku

  • setPreferredDevice() ustawia preferowane urządzenie do routingu dźwięku. Użytkownik może zastąpić to ustawienie w ustawieniach systemu.

Adapter Bluetooth

Przewodniki według przypadku użycia

Poniżej znajdziesz wytyczne dotyczące wdrażania LEA w zależności od konkretnych przypadków użycia.

Aplikacje do komunikacji głosowej

Aplikacje do komunikacji głosowej mogą zarządzać routingiem dźwięku i stanem urządzenia, samodzielnie zarządzając stanem lub korzystając z interfejsu Telecom API, który wykonuje routing dźwięku i logikę stanu.

Te 2 rozwiązania umożliwiają szybkie i łatwe sterowanie kierowaniem dźwięku oraz przełączanie się między urządzeniami Bluetooth. Więcej informacji znajdziesz w przewodniku po połączeniach zarządzanych przez operatora.

Aplikacje do nagrywania dźwięku

  • Rejestrator multimediów: podczas nagrywania dźwięku za pomocą Rejestratora multimediów możesz teraz nagrywać w stereo, jeśli słuchawki Bluetooth obsługują LEA. Zapoznaj się z przewodnikiem po nagrywaniu dźwięku.

Rekomendacje dotyczące zestawów słuchawkowych

W miarę wprowadzania na rynek kolejnych zestawów słuchawkowych LEA odkryliśmy w testach w rzeczywistych warunkach problemy, które pogarszają komfort użytkowania. Specyfikacja nie obejmuje wszystkich tych problemów. W tabeli poniżej znajdziesz listę zaleceń, których producenci słuchawek LEA powinni przestrzegać, aby poprawić komfort korzystania z nich przez użytkowników Androida.

Opis Kontekst
Obsługa wyprowadzania kluczy transportowych (CTKD) w przypadku słuchawek dwumodowych:
  • Obsługa wyprowadzania kluczy zarówno w przypadku parowania Classic-to-LE, jak i LE-to-Classic.
 Większość nowych zestawów słuchawkowych LEA będzie dwutrybowa, dopóki nie wzrośnie udział w rynku urządzeń źródłowych LEA. Ważne jest, aby użytkownicy mogli bezproblemowo sparować słuchawki dwumodalne i skonfigurować oba tryby transmisji. Jest to również ważne w przypadku szybkiego parowania Google.

Obsługuj ukierunkowane ogłoszenia, jeśli chcesz, aby słuchawki LEA niezawodnie ponownie łączyły się z urządzeniami źródłowymi.

Słuchawki douszne LE Audio powinny używać TA do wysyłania żądań połączeń przychodzących z urządzeń centralnych.

Zostanie dodany do nadchodzącego BT SIG.

 W przeciwieństwie do modelu przywoływania BR/EDR, w którym połączenie może być inicjowane przez telefon lub słuchawki, w przypadku LEA połączenie musi być inicjowane przez urządzenie centralne. Obecnie wiele zestawów słuchawkowych nie korzysta z TA, co oznacza, że urządzenie centralne może nie być w stanie ponownie połączyć się z urządzeniem peryferyjnym bez dodania go do listy dozwolonych. Obejście w postaci listy dozwolonych może jednak uniemożliwić połączenie zestawu słuchawkowego z innym urządzeniem centralnym. Dlatego ważne jest, aby słuchawki LEA prawidłowo obsługiwały TA, tak aby urządzenie centralne mogło niezawodnie ponownie się połączyć bez obejść, które mogłyby przerwać połączenia wielopunktowe.
Zoptymalizowana wykrywalność słuchawek dousznych w trybie podwójnym
  • Główna słuchawka – komponent BR/EDR powinna reklamować się za pomocą adresu publicznego i umożliwiać skanowanie zapytań i stron, a jej nazwa powinna być dostępna w EIR. W przypadku głównej klasy usług klasy urządzenia (CoD) powinna ustawić bit 14 dźwięku LE na 1.
  • Słuchawka podstawowa – komponent LE: słuchawka podstawowa powinna wysyłać reklamę z możliwością połączenia i wykrycia (ograniczoną lub ogólną) przy użyciu tego samego adresu publicznego co komponent BR/EDR i tej samej pełnej nazwy lokalnej co komponent BR/EDR, z ustawioną kategorią wyglądu na odpowiednią kategorię wyglądu, która pasuje do typu urządzenia zdalnego, przy założeniu, że urządzenie centralne będzie używać tych informacji do dostosowywania interfejsu i zasad routingu dźwięku.
  • Słuchawka dodatkowa – tylko LE: słuchawka dodatkowa powinna wysyłać reklamę z możliwością połączenia, ale bez możliwości wykrycia, z kategorią wyglądu ustawioną na odpowiednią kategorię wyglądu, która pasuje do typu urządzenia zdalnego. Oczekuje się, że urządzenie centralne wykorzysta te informacje do dostosowania interfejsu i zasad routingu audio.

    Słuchawki douszne powinny dynamicznie wybierać lidera z grupy CSIP, który będzie urządzeniem głównym. Jeśli słuchawka jest dwutrybowa, urządzenie główne musi być dwutrybowe, aby po sparowaniu obie funkcje LE i Classic działały prawidłowo.

 Zapobiega to wyświetlaniu słuchawek dousznych LEA w trybie podwójnym jako duplikatów w ustawieniach Bluetooth, co może wprowadzać użytkowników w błąd i pogarszać wrażenia z parowania LEA.

Dynamiczne wybieranie lidera jest szczególnie ważne w przypadku urządzeń dwutrybowych, które są parowane przyrostowo. Jeśli na przykład podczas początkowego parowania dostępna jest tylko jedna słuchawka, powinna być ona prezentowana jako urządzenie dwutrybowe. Gdy użytkownik sparuje drugą słuchawkę, wystarczy, że sparuje ją z komponentem LE, a CSIP zadba o to, aby były one zgrupowane na urządzeniu z Androidem.

Adres tożsamości jest zalecany podczas parowania, ponieważ komponent BR/EDR udostępnia już publiczny adres urządzenia urządzeniom w pobliżu.
Obsługa protokołu ulepszonych atrybutów (EATT). Zmniejsza opóźnienie parowania i połączenia.
Obsługa solidnego buforowania GATT. Zmniejsza opóźnienie połączenia, zwłaszcza w przypadku słuchawek TWS.
Obsługa oceny połączenia. Umożliwia bardziej elastyczne planowanie pakietów i potencjalne oszczędzanie baterii.
Upewnij się, że podczas przetwarzania wstępnego i końcowego zarówno w przypadku odtwarzania, jak i nagrywania potok przetwarzania sygnału może działać z częstotliwością 16, 24, 32 i 48 kHz, a także obsługiwać wyższe częstotliwości. Wykorzystuje wyższe częstotliwości próbkowania obsługiwane w przypadku połączeń LEA lub ścieżek przechwytywania VoIP i odtwarzania multimediów.
Obsługa LE Power Control lepsze zarządzanie zasilaniem,

Obsługa typu kontekstu

Opis Kontekst
Używaj wszystkich typów kontekstu określonych w sekcji Assigned Numbers 6.12.3, chyba że zestaw słuchawkowy wyraźnie nie obsługuje danego typu kontekstu. Jeśli na przykład typ kontekstu „Gra” nie jest obsługiwany, Android będzie wysyłać dźwięki z gier. Pamiętaj, że typ kontekstu „Nie określono” nie oznacza „dowolnego typu kontekstu” ani nie obejmuje nieobsługiwanych typów kontekstu.

Gdy urządzenie centralne wchodzi w interakcję z ASCS urządzenia peryferyjnego, urządzenie peryferyjne musi połączyć się z MCS i TBS urządzenia centralnego.

Urządzenie centralne nie zawsze może używać dźwięku LE jako ścieżki przesyłania strumieniowego, ponieważ może powrócić do korzystania z A2DP lub HFP. Urządzenie peryferyjne może używać interakcji ASCS jako wskazówki, czy urządzenie centralne będzie używać dźwięku LE do przesyłania strumieniowego.

Przykłady interakcji ASCS to odczyt, zapis i rejestracja powiadomień.

Zalecenia dotyczące nadajników Auracast

W tej sekcji znajdziesz rekomendacje dotyczące konfigurowania nadajników Auracast.

Transmisje przerywane

Komunikaty audio w miejscach publicznych, takich jak terminale transportu publicznego, są często przerywane i oddzielone długimi okresami ciszy. Ciągłe przesyłanie strumieniowe ciszy lub dźwięku w tle między komunikatami marnuje energię odbiornika i uniemożliwia użytkownikom słuchanie głównego strumienia audio, takiego jak lokalne media lub inny aktywny strumień Auracast.

Aby zwiększyć komfort użytkowników, Android zaleca, aby nadajniki Auracast przestrzegały tych wytycznych dotyczących obsługi przerywanych transmisji.

Definicje

  • Dźwięk o znaczeniu: podstawowe treści informacyjne przeznaczone dla użytkownika, np. komunikat na lotnisku lub dworcu.
  • Dźwięk w tle: cisza w tle, szum lub muzyka w tle przesyłane między okresami dźwięku, który Cię interesuje.
  • Przerwy w transmisji: transmisja, która na przemian zawiera okresy z interesującym dźwiękiem i okresy z dźwiękiem w tle lub bez dźwięku.

Identyfikowanie przerywanych transmisji

Aby oznaczyć transmisję jako przerywaną, nadawca powinien umieścić strukturę metadanych Audio_Active_State LTV (Length-Type-Value) [1] w 2 miejscach:

  1. Struktura BASE metadanych poziomu 2 (reklamy okresowe) [2]
  2. Metadane ogłoszenia publicznego (rozszerzone reklamy) [3]

Aby pomóc odbiorcy zidentyfikować transmisję przerywaną i zdecydować, czy odtworzyć strumień, nadawca powinien też dokładnie ustawić strukturę LTV metadanych Streaming_Audio_Context [1].

Identyfikowanie interesujących fragmentów audio

Aby dynamicznie sygnalizować, czy transmisja przerywana zawiera w danym momencie dźwięk, który może zainteresować użytkownika, nadajnik używa struktur LTV metadanych Audio_Active_State.

  • Metadane struktury BASE poziomu 2: wartość 0x01 oznacza, że BIS w podgrupie zawiera obecnie dźwięk, który może zainteresować użytkownika.
  • Metadane ogłoszenia publicznego: wartość 0x01 oznacza, że co najmniej jeden z bloków BIS w ramach bloku BIG zawiera dźwięk, który może zainteresować użytkownika.

Wartości LTV metadanych Audio_Active_State powinny być ustawione na 0x01 na krótko przed transmisją dźwięku, który może zainteresować użytkownika, co umożliwi urządzeniu skanującemu synchronizację ze źródłem transmisji publicznej. Z kolei krótko po zakończeniu transmisji powinna być ustawiona na 0x00.

Wykorzystywanie kontekstu strumieniowych reklam audio

Podanie wyraźnego kontekstu pomaga platformie Android i urządzeniom odbierającym określać priorytety przychodzących strumieni. Na przykład system nagłośnienia może ustawić typ Streaming_Audio_Context na Instructional, aby komunikaty mogły bezproblemowo przerywać odtwarzanie lokalnych multimediów na odbiorniku i płynnie je wznawiać.

Odniesienia

[1] Bluetooth Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers/
[2] Basic Audio Profile, https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0-3/
[3] Public Broadcast Profile, https://www.bluetooth.com/specifications/specs/public-broadcast-profile-1-0-2/