Bluetooth Low Energy-Audio

Bluetooth LEA (Low Energy Audio) sorgt dafür, dass Nutzer Audio in hoher Qualität empfangen können, ohne dass die Akkulaufzeit darunter leidet. Außerdem können sie nahtlos zwischen verschiedenen Anwendungsfällen wechseln. Android 13 (API‑Level 33) bietet integrierte Unterstützung für LEA.

Die meisten LEA-Headsets sind Dual-Mode-Headsets, bis der Marktanteil von LEA-Quellgeräten wächst. Nutzer sollten beide Übertragungsarten auf ihren Dual-Mode-Headsets koppeln und einrichten können.

Anwendungsfälle

Sie können LEA für die folgenden Anwendungsfälle einbinden:

  • Audio freigeben: Nutzer können gleichzeitig mehrere Audio-Streams für ein oder mehrere Audio-Senkengeräte freigeben. Audio wird zwischen dem Quellgerät und verbundenen Geräten synchronisiert.

  • Audio übertragen: Nutzer können Audioinhalte an Freunde und Familie übertragen und sich gleichzeitig mit öffentlichen Übertragungen verbinden, um Informationen, Unterhaltung oder Barrierefreiheit zu erhalten.

  • Unterstützung für den LC3-Audio-Codec: Dies ist der Standard-Audio-Codec und ersetzt den SBC-Codec, der für A2DP (Media) und mSBC in HFP (Voice) verwendet wird. LC3 ist effizienter, rekonfigurierbar und bietet eine höhere Qualität.

  • Verbesserungen bei der Audioabtastung: Headsets können bei der Verwendung von Mikrofonen eine hohe Audioqualität beibehalten. Bei Verwendung von Bluetooth-Mikrofonen wird die Audioqualität durch Bluetooth Classic verringert. Mit BLE Audio kann die Ein- und Ausgabesamplingrate bis zu 32 kHz betragen.

  • Stereomikrofon: Hearables können Audio mit Stereomikrofonen aufnehmen, um Spatial Audio zu verbessern.

  • Unterstützung für das Hearing Aid Profile (HAP): HAP bietet Nutzern eine bessere Barrierefreiheit und Nutzung als frühere ASHA-Protokolle. Nutzer können ihre Hörgeräte für Telefonanrufe und VoIP-Anwendungen verwenden.

  • Unterstützung des Enhanced Attribute Protocol (EATT): Mit EATT können Entwickler mehrere Befehle gleichzeitig an gekoppelte Hearables senden.

Wichtige Szenarien

Es gibt vier Hauptkategorien von Anwendungsfällen:

  1. Konversation: Dialer- und VoIP-Anwendungen, die ein Kommunikationsrouting mit niedriger Latenz erfordern, bieten eine hohe Audioqualität und eine geringere Akkunutzung.

  2. Gaming: Gleichzeitige Mikrofon- und Hi-Fi-Wiedergabe ermöglicht das Streamen von hochwertigem Audio zu Hearables. Eine Gaming-App kann auf BLE-Audioeingaben zugreifen, wenn ein Spiel das Bluetooth-Mikrofon als einsatzbereit markiert. Wenn ein Spieler dann eine Live-Unterhaltung mit einem anderen Spieler startet, kann die Spiel-App die Mikrofondaten ohne Verzögerung verwenden.

  3. Media: Media-Anwendungen dürfen das bevorzugte Gerät des Audio-Managers festlegen. Nutzer können dies überschreiben, indem sie das bevorzugte Gerät in den Systemeinstellungen ändern.

  4. Bedienungshilfe: Hörgeräte, die BLE Audio unterstützen, können jetzt das Mikrofon verwenden. Nutzer können ihre Hörgeräte also während eines Anrufs durchgehend verwenden.

BLE Audio-APIs und ‑Methoden

Die folgenden APIs und Methoden sind erforderlich, um BLE Audio-Hearables zu unterstützen:

AudioManager

  • setCommunicationDevice(): Wählt das Audiogerät aus, das für Kommunikationsanwendungsfälle wie Sprach- oder Videoanrufe verwendet werden soll. Diese Methode kann von Sprach- oder Videoanruf-Anwendungen verwendet werden, um ein anderes Audiogerät als das von der Plattform standardmäßig ausgewählte auszuwählen. Diese API ersetzt die folgenden verworfenen APIs: startBluetoothSco(), stopBluetoothSco(), und setSpeakerphoneOn().
  • clearCommunicationDevice() wird aufgerufen, nachdem Ihre App einen Anruf oder eine Sitzung beendet hat. So soll sichergestellt werden, dass Nutzer beim Wechsel zwischen verschiedenen Anwendungen eine gute Erfahrung machen.

BluetoothProfile

Telecom InCallService

Telecom CallControl

Informationen zum Audiogerät

Audiorekorder

  • Mit setPreferredDevice() wird das bevorzugte Gerät für das Audio-Routing festgelegt. Der Nutzer kann dies in den Systemeinstellungen überschreiben.

Bluetooth-Adapter

Leitfäden nach Anwendungsfall

Im Folgenden finden Sie Richtlinien für die Implementierung von LEA basierend auf bestimmten Anwendungsfällen.

Sprachkommunikationsanwendungen

Sprachkommunikationsanwendungen haben die Möglichkeit, das Audio-Routing und den Gerätestatus selbst zu verwalten oder die Telecom API zu verwenden, die das Audio-Routing und die Statuslogik für Sie übernimmt.

Mit diesen beiden Lösungen können Sie das Audiorouting schnell und einfach steuern und zwischen Bluetooth-Geräten wechseln. Weitere Informationen finden Sie im Leitfaden zu von Telekommunikationsunternehmen verwalteten Anrufen.

Apps für Audioaufnahmen

  • Media Recorder: Wenn Sie Audio mit dem Media Recorder aufnehmen, können Sie jetzt in Stereo aufnehmen, wenn das Bluetooth-Hörgerät LEA unterstützt. Leitfaden für Audioaufnahmen

Empfehlungen für Headsets

Mit der Veröffentlichung weiterer LEA-Headsets haben wir bei Tests in der Praxis Probleme festgestellt, die die Nutzerfreundlichkeit beeinträchtigen. Die Spezifikation deckt nicht alle diese Probleme ab. In der folgenden Tabelle finden Sie eine Liste von Empfehlungen, die Hersteller von LEA-Headsets befolgen sollten, um die End-to-End-Erfahrung für Android-Nutzer zu verbessern.

Beschreibung Kontext
Unterstützung von Cross Transport Key Derivation (CTKD) für Dual-Mode-Headsets:
  • Unterstützung der Schlüsselableitung für die Kopplung von Classic zu LE und von LE zu Classic.
 Die meisten neuen LEA-Headsets sind Dual-Mode-Headsets, bis der Marktanteil von LEA-Quellgeräten steigt. Es ist wichtig, dass Nutzer ihre Dual-Mode-Headsets nahtlos koppeln und beide Übertragungsarten einrichten können. Das ist auch für Google Schnelles Pairing wichtig.

Unterstützung von Targeted Announcements (TAs), wenn Ihre LEA-Headsets zuverlässig mit den Quellgeräten verbunden werden sollen.

LE-Audio-Kopfhörer sollten TAs verwenden, um eine eingehende Verbindung von den zentralen Geräten anzufordern.

Wird in der nächsten BT SIG hinzugefügt.

 Im Gegensatz zum Paging-Modell von BR/EDR, bei dem eine Verbindung entweder vom Smartphone oder vom Headset initiiert werden kann, muss eine Verbindung in LEA vom zentralen Gerät initiiert werden. Derzeit verwenden viele Headsets keine TAs. Das bedeutet, dass das zentrale Gerät möglicherweise keine Verbindung zum Peripheriegerät herstellen kann, ohne es einer Zulassungsliste hinzuzufügen. Durch eine Umgehung der Zulassungsliste kann jedoch verhindert werden, dass das Headset eine Verbindung zu einem anderen zentralen Gerät herstellt. Daher ist es wichtig, dass Headsets für Strafverfolgungsbehörden TAs richtig unterstützen, damit das zentrale Gerät zuverlässig wieder verbunden werden kann, ohne dass Workarounds erforderlich sind, die Multipoint-Verbindungen unterbrechen könnten.
Optimierte Auffindbarkeit für Dual-Mode-Kopfhörer
  • Der primäre Kopfhörer – BR/EDR-Komponente sollte mit seiner öffentlichen Adresse werben, Inquiry und Page Scan mit seinem Namen ermöglichen, der über EIR verfügbar ist, und das LE-Audio-Bit 14 in den Major Service Classes der Class of Device (CoD) auf 1 setzen.
  • Primärer Kopfhörer – LE-Komponente: Der primäre Kopfhörer sollte eine Connectable- und Discoverable-Ankündigung (entweder Limited oder General) mit derselben öffentlichen Adresse wie die BR/EDR-Komponente und demselben vollständigen lokalen Namen wie die BR/EDR-Komponente ausführen. Die Appearance Category sollte auf eine geeignete Appearance Category festgelegt werden, die dem Typ des Remote-Geräts entspricht. Es wird erwartet, dass das zentrale Gerät diese Informationen verwendet, um seine Benutzeroberfläche und die Audio-Routing-Richtlinien anzupassen.
  • Sekundärer Kopfhörer – nur LE: Der sekundäre Kopfhörer sollte eine Connectable, Non-Discoverable-Ankündigung mit seiner Appearance Category als geeignete Appearance Category ausführen, die dem Typ des Remote-Geräts entspricht. Es wird erwartet, dass das zentrale Gerät diese Informationen verwendet, um seine Benutzeroberfläche und Audio-Routing-Richtlinien anzupassen.

    Die Kopfhörer sollten dynamisch ein primäres Gerät aus der CSIP-Gruppe auswählen. Wenn der Kopfhörer Dual-Mode unterstützt, muss das primäre Gerät Dual-Mode unterstützen, damit sowohl LE- als auch Classic-Funktionen nach dem Koppeln richtig funktionieren.

 So wird verhindert, dass Dual-Mode-LEA-Kopfhörer als doppelte Einträge in den Bluetooth-Einstellungen angezeigt werden. Dies könnte Nutzer verwirren und die LEA-Kopplung beeinträchtigen.

Die dynamische Leader-Auswahl ist besonders wichtig für Geräte im Dual-Modus, die inkrementell gekoppelt werden. Wenn beispielsweise beim ersten Koppeln nur ein Kopfhörer verfügbar ist, sollte er als Dual-Mode-Gerät angezeigt werden. Wenn ein Nutzer später den zweiten Kopfhörer koppelt, muss er ihn nur mit der LE-Komponente koppeln. CSIP sorgt dafür, dass sie auf Android gruppiert werden.

Die Identitätsadresse wird während des Pairings empfohlen, da die BR/EDR-Komponente die öffentliche Adresse des Geräts bereits für Geräte in der Nähe verfügbar macht.
Unterstützung des Enhanced Attribute Protocol (EATT) Reduziert die Latenzzeit beim Koppeln und Verbinden.
Unterstützung für Robust GATT Caching. Verringert die Latenzzeit der Verbindung, insbesondere bei TWS-Kopfhörern.
Unterstützung von Verbindungs-Subrating. Ermöglicht eine flexiblere Paketplanung und kann den Akkuverbrauch senken.
Achte darauf, dass die Signalverarbeitungspipeline sowohl bei der Vor- als auch bei der Nachbearbeitung für die Wiedergabe und Aufnahme mit 16, 24, 32 und 48 kHz betrieben werden kann und auch höhere Frequenzen unterstützt. Nutzt die höheren Samplingraten, die für LEA-Anruf- oder VoIP-Erfassungs- und Medienwiedergabepfade unterstützt werden.
Unterstützung von LE Power Control Verbessertes Energiemanagement

Unterstützung von Kontexttypen

Beschreibung Kontext
Verwende alle in Assigned Numbers 6.12.3 angegebenen Kontexttypen, sofern das Headset einen bestimmten Kontexttyp nicht explizit unterstützt. Wenn beispielsweise der Kontexttyp „Spiel“ nicht unterstützt wird, sendet Android Spielgeräusche. Beachten Sie insbesondere, dass der Kontexttyp „Nicht angegeben“ nicht „beliebiger Kontexttyp“ bedeutet und nicht unterstützte Kontexttypen nicht abdeckt.

Wenn das zentrale Gerät mit den ASCS des Peripheriegeräts interagiert, muss das Peripheriegerät eine Verbindung zum MCS und TBS des zentralen Geräts herstellen.

Das zentrale Gerät verwendet möglicherweise nicht immer LE Audio als Streamingroute, da es möglicherweise auf A2DP oder HFP zurückgreift. Das Peripheriegerät kann die ASCS-Interaktion als Hinweis darauf verwenden, ob das zentrale Gerät LE Audio für das Streaming verwenden wird.

Beispiele für ASCS-Interaktionen sind „Lesen“, „Schreiben“ und „Für Benachrichtigung registrieren“.

Empfehlungen für Auracast-Sender

Dieser Abschnitt enthält Empfehlungen für die Konfiguration von Auracast-Sendern.

Unterbrochene Übertragungen

Audioansagen an öffentlichen Orten wie Verkehrsknotenpunkten sind oft nur zeitweise und durch lange Pausen getrennt. Wenn zwischen Ankündigungen kontinuierlich Stille oder Hintergrundaudio gestreamt wird, wird die Leistung des Empfängers verschwendet und Nutzer können nicht ihren primären Audiostream hören, z. B. lokale Medien oder einen anderen aktiven Auracast-Stream.

Um die Nutzerfreundlichkeit zu verbessern, empfiehlt Android, dass Auracast-Sender die folgenden Richtlinien für den Umgang mit zeitweiligen Übertragungen einhalten.

Definitionen

  • Audio-of-Interest:Die wichtigsten Informationen für den Nutzer, z. B. eine Gate- oder Zugansage.
  • Hintergrundaudio:Stille, Rauschen oder Hintergrundmusik, die zwischen den Zeiträumen mit Audio-of-Interest übertragen wird.
  • Unterbrochene Übertragung:Eine Übertragung, bei der sich Phasen mit Audio-of-Interest und Phasen mit Hintergrundaudio oder gar kein Audio abwechseln.

Vorübergehende Übertragungen erkennen

Um eine Sendung als „Intermittent Broadcast“ zu kennzeichnen, sollte der Sender die LTV-Struktur (Length-Type-Value) der Audio_Active_State-Metadaten[1] an zwei Stellen einfügen:

  1. Die BASE-Struktur „Level 2 Metadata (Periodic Advertisements)“ [2]
  2. Metadaten für Ankündigungen öffentlicher Übertragungen (erweiterte Werbung) [3]

Damit der Empfänger die intermittierende Übertragung identifizieren und entscheiden kann, ob er den Stream abspielen soll, muss der Broadcaster auch die LTV-Struktur der Streaming_Audio_Context-Metadaten [1] korrekt festlegen.

Audio-of-Interest identifizieren

Um dynamisch zu signalisieren, ob eine intermittierende Übertragung zu einem bestimmten Zeitpunkt Audio-of-Interest enthält, verwendet der Sender die LTV-Strukturen der Metadaten Audio_Active_State.

  • BASE-Struktur, Metadaten der Ebene 2:Der Wert „0x01“ gibt an, dass die BISes in einer Untergruppe derzeit Audio-of-Interest enthalten.
  • Metadaten für öffentliche Broadcast-Ankündigungen:Der Wert „0x01“ gibt an, dass mindestens ein BIS in einem BIG Audio-of-Interest enthält.

Die LTV-Werte für die Audio_Active_State-Metadaten sollten kurz vor der Übertragung von Audio-of-Interest auf 0x01 gesetzt werden, damit ein Scan-Gerät mit einer Public Broadcast Source synchronisiert werden kann. Umgekehrt sollte sie kurz nach Ende der Übertragung auf 0x00 gesetzt werden.

Streaming-Audiokontext nutzen

Wenn Sie expliziten Kontext angeben, können das Android-Framework und die empfangenden Geräte eingehende Streams priorisieren. Beispielsweise kann ein Beschallungssystem den Typ „Streaming_Audio_Context“ auf „Instructional“ festlegen, damit Ansagen die lokale Medienwiedergabe eines Empfängers unterbrechen und danach nahtlos fortsetzen können.

Verweise

[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/