Audio Bluetooth à basse consommation

Le Bluetooth Low Energy Audio (LEA) permet aux utilisateurs de recevoir un son haute fidélité sans sacrifier l'autonomie de la batterie et de passer facilement d'un cas d'utilisation à un autre. Android 13 (niveau d'API 33) inclut la prise en charge intégrée de LEA.

La plupart des casques LEA seront bimodes jusqu'à ce que la part de marché des appareils sources LEA augmente. Les utilisateurs doivent pouvoir associer et configurer les deux modes de transmission sur leurs casques bimodes.

Cas d'utilisation

Vous pouvez intégrer LEA pour les cas d'utilisation suivants :

  • Partage audio : les utilisateurs peuvent partager simultanément plusieurs flux audio vers un ou plusieurs appareils récepteurs audio. L'audio est synchronisé entre l'appareil source et les appareils connectés.

  • Diffuser du contenu audio : les utilisateurs peuvent diffuser du contenu audio à leurs amis et à leur famille, tout en se connectant à des diffusions publiques pour obtenir des informations, se divertir ou accéder à des contenus.

  • Prise en charge du codec audio LC3 : il s'agit du codec audio par défaut, qui remplace le codec SBC utilisé pour A2DP (média) et mSBC dans HFP (voix). LC3 est plus efficace, reconfigurable et de meilleure qualité.

  • Améliorations de l'échantillonnage audio : les casques peuvent maintenir une qualité audio de sortie élevée lors de l'utilisation de micros. Le Bluetooth classique réduit la qualité audio lorsque vous utilisez des micros Bluetooth. Avec BLE Audio, l'échantillonnage d'entrée et de sortie peut atteindre 32 kHz.

  • Micro stéréo : les wearables peuvent enregistrer de l'audio avec des micros stéréo pour améliorer le son spatial.

  • Compatibilité avec le profil d'appareil auditif (HAP) : le profil HAP offre aux utilisateurs une accessibilité et une utilisation supérieures à celles des protocoles ASHA précédents. Les utilisateurs peuvent utiliser leurs appareils auditifs pour les appels téléphoniques et les applications VoIP.

  • Prise en charge du protocole EATT (Enhanced Attribute Protocol) : EATT permet aux développeurs d'envoyer plusieurs commandes à la fois aux appareils auditifs associés.

Scénarios clés

Il existe quatre principales catégories de cas d'utilisation :

  1. Conversationnel : les applications de numérotation et de VoIP qui nécessitent un routage de communication à faible latence offrent un son de haute qualité et consomment moins de batterie.

  2. Jeux : la lecture simultanée du micro et du son haute fidélité permet aux jeux de diffuser un son de haute qualité vers les appareils auditifs. Une application de jeu peut accéder à l'entrée audio BLE lorsqu'un jeu active le micro Bluetooth comme prêt à l'emploi. Ensuite, lorsqu'un joueur démarre une conversation en direct avec un autre joueur, l'application de jeu peut utiliser les données du micro sans délai.

  3. Multimédia : les applications multimédias sont autorisées à définir l'appareil par défaut du gestionnaire audio. L'utilisateur peut remplacer ce paramètre en modifiant son appareil par défaut dans les paramètres du système.

  4. Accessibilité : les appareils auditifs compatibles avec BLE Audio peuvent désormais utiliser le micro, ce qui permet aux utilisateurs de continuer à les utiliser pour un appel.

API et méthodes audio BLE

Les API et méthodes suivantes sont requises pour prendre en charge les appareils auditifs BLE Audio :

AudioManager

  • setCommunicationDevice() sélectionne le périphérique audio à utiliser pour les communications, par exemple les appels vocaux ou vidéo. Cette méthode peut être utilisée par les applications de chat vocal ou vidéo pour sélectionner un autre appareil audio que celui sélectionné par défaut par la plate-forme. Cette API remplace les API obsolètes suivantes : startBluetoothSco(), stopBluetoothSco(), et setSpeakerphoneOn().
  • clearCommunicationDevice() est appelé une fois que votre application a terminé un appel ou une session pour garantir une expérience utilisateur optimale lors du passage d'une application à une autre.

BluetoothProfile

Telecom InCallService

Telecom CallControl

Informations sur l'appareil audio

Enregistreur audio

  • setPreferredDevice() définit l'appareil par défaut à utiliser pour le routage audio. L'utilisateur peut remplacer ce paramètre dans les paramètres système.

Adaptateur Bluetooth

Guides basés sur les cas d'utilisation

Vous trouverez ci-dessous des consignes pour implémenter LEA en fonction de cas d'utilisation spécifiques.

Applications de communication vocale

Les applications de communication vocale peuvent choisir de gérer elles-mêmes l'état de l'appareil et le routage audio, ou d'utiliser l'API Telecom, qui gère la logique d'état et de routage audio pour vous.

Ces deux solutions vous permettent de contrôler rapidement et facilement le routage audio et de basculer entre les appareils Bluetooth. Pour en savoir plus, consultez le guide sur les appels gérés par l'opérateur télécom.

Applications d'enregistrement audio

  • Enregistreur multimédia : lorsque vous enregistrez de l'audio à l'aide de l'Enregistreur multimédia, vous pouvez désormais enregistrer en stéréo si l'appareil auditif Bluetooth est compatible avec LEA. Consultez le guide sur l'enregistrement audio.

Recommandations concernant les casques

Au fur et à mesure de la sortie de casques LEA, nous avons découvert des problèmes lors de tests en conditions réelles qui dégradent l'expérience utilisateur. La spécification ne couvre pas tous ces problèmes. Le tableau suivant fournit une liste de recommandations que les fabricants de casques LEA doivent suivre pour améliorer l'expérience de bout en bout des utilisateurs Android.

Description Contexte
Prise en charge de la dérivation de clé de transport croisée (CTKD) pour les casques bimodes :
  • Prend en charge la dérivation de clé pour l'association Classic-to-LE et LE-to-Classic.
 La plupart des nouveaux casques LEA seront bimodes jusqu'à ce que la part de marché des appareils sources LEA augmente. Il est important que les utilisateurs puissent associer leurs casques bimodes de manière fluide et configurer les deux modes de transmission. C'est également important pour Google Fast Pair.

Prenez en charge les annonces ciblées si vous souhaitez que vos casques LEA se reconnectent de manière fiable aux appareils sources.

Les écouteurs LE Audio doivent utiliser des TA pour demander une connexion entrante depuis les appareils centraux.

Sera ajouté à la prochaine BT SIG.

 Contrairement au modèle de pagination BR/EDR où une connexion peut être initiée par le téléphone ou le casque, une connexion LEA doit être initiée par l'appareil central. Actuellement, de nombreux casques n'utilisent pas de TA, ce qui signifie que l'appareil central peut ne pas être en mesure de se reconnecter au périphérique sans l'ajouter à une liste d'autorisation. Toutefois, une solution de contournement de la liste d'autorisation peut empêcher le casque de se connecter à un autre appareil central. Il est donc important que les casques LEA soient compatibles avec les TA afin que l'appareil central puisse se reconnecter de manière fiable sans contournement qui pourrait interrompre les connexions multipoints.
Découvrabilité optimisée pour les écouteurs à double mode
  • L'écouteur principal (composant BR/EDR) doit diffuser des annonces à l'aide de son adresse publique, activer la découverte et l'analyse des pages avec son nom disponible via EIR, et définir le bit audio LE 14 sur 1 dans les classes de service principales de la classe d'appareil (CoD).
  • Écouteur principal – Composant LE : l'écouteur principal doit effectuer une publicité Connectable et Discoverable (limitée ou générale) en utilisant la même adresse publique que le composant BR/EDR et le même nom local complet que le composant BR/EDR, avec sa catégorie d'apparence définie sur une catégorie d'apparence appropriée correspondant au type d'appareil distant, en s'attendant à ce que l'appareil central utilise ces informations pour ajuster ses règles d'interface utilisateur et de routage audio.
  • Écouteur secondaire (LE uniquement) : l'écouteur secondaire doit effectuer une publicité connectable et non détectable avec sa catégorie d'apparence définie sur une catégorie d'apparence appropriée correspondant au type d'appareil distant, en s'attendant à ce que l'appareil central utilise ces informations pour ajuster son interface utilisateur et ses règles de routage audio.

    Les écouteurs doivent élire dynamiquement un leader du groupe CSIP comme appareil principal. Si l'écouteur est bimode, l'appareil principal doit l'être également pour que les fonctionnalités LE et Classic fonctionnent correctement après l'association.

 Cela empêche les écouteurs LEA bimodes d'apparaître comme des entrées en double dans les paramètres Bluetooth, ce qui pourrait dérouter les utilisateurs et compromettre l'expérience d'association LEA.

L'élection dynamique du leader est particulièrement importante pour les appareils à double mode qui sont associés de manière incrémentielle. Par exemple, si un seul écouteur est disponible lors du premier appairage, il doit se présenter comme un appareil à double mode. Lorsqu'un utilisateur associe le deuxième écouteur ultérieurement, il n'a besoin de l'associer qu'au composant LE. CSIP s'assurera qu'ils sont regroupés sur Android.

L'adresse d'identité est recommandée lors de l'association, car le composant BR/EDR expose déjà l'adresse publique de l'appareil aux appareils à proximité.
Prise en charge du protocole EATT (Enhanced Attribute Protocol). Réduit la latence de l'association et de la connexion.
Compatibilité avec la mise en cache GATT robuste. Réduit la latence de connexion, en particulier pour les écouteurs TWS.
Prise en charge de la sous-évaluation de la connexion. Permet une planification des paquets plus flexible et des économies de batterie potentielles.
Assurez-vous que, pendant le prétraitement et le post-traitement pour la lecture et la capture, le pipeline de traitement du signal peut fonctionner à 16, 24, 32 et 48 kHz, et prendre en charge des fréquences plus élevées. Profite des taux d'échantillonnage plus élevés pris en charge pour les chemins de capture d'appels LEA ou VoIP et la lecture multimédia.
Compatibilité avec LE Power Control Meilleure gestion de l'alimentation

Compatibilité avec les types de contexte

Description Contexte
Utilisez tous les types de contexte spécifiés dans Assigned Numbers 6.12.3, sauf si le casque ne prend pas explicitement en charge un type de contexte donné. Par exemple, si le type de contexte "Jeu" n'est pas pris en charge, Android enverra des sons de jeu. En particulier, notez que le type de contexte "Non spécifié" ne signifie pas "tout type de contexte" et ne couvre pas les types de contexte non compatibles.

Lorsque l'appareil central interagit avec l'ASCS de l'appareil périphérique, ce dernier doit se connecter au MCS et au TBS de l'appareil central.

Il est possible que l'appareil central n'utilise pas toujours LE Audio comme route de streaming, car il peut revenir à l'utilisation d'A2DP ou de HFP. L'appareil périphérique peut utiliser l'interaction ASCS pour indiquer si l'appareil central utilisera LE Audio pour le streaming.

Voici quelques exemples d'interactions ASCS : lecture, écriture et enregistrement pour la notification.

Recommandations pour les émetteurs Auracast

Cette section fournit des recommandations pour configurer les émetteurs Auracast.

Diffusions intermittentes

Les annonces audio dans les lieux publics, comme les terminaux de transport en commun, sont souvent intermittentes et séparées par de longues périodes de silence. La diffusion en continu de silence ou d'un son de fond entre les annonces gaspille l'énergie du récepteur et empêche les utilisateurs d'écouter leur flux audio principal, comme un contenu multimédia local ou un autre flux Auracast actif.

Pour améliorer l'expérience utilisateur, Android recommande aux émetteurs Auracast de respecter les consignes suivantes pour gérer les diffusions intermittentes.

Définitions

  • Contenu audio d'intérêt : contenu informationnel principal destiné à l'utilisateur, comme une annonce de porte ou de train.
  • Audio de fond : silence, bruit statique ou musique ambiante transmis entre les périodes d'audio d'intérêt.
  • Diffusion intermittente : diffusion qui alterne entre des périodes d'audio d'intérêt et des périodes d'audio de fond ou sans audio du tout.

Identifier les diffusions intermittentes

Pour désigner une diffusion comme une diffusion intermittente, le diffuseur doit inclure la structure LTV (Length-Type-Value) des métadonnées Audio_Active_State [1] à deux endroits :

  1. Métadonnées de niveau 2 de la structure BASE (annonces périodiques) [2]
  2. Métadonnées de l'annonce de diffusion publique (annonces étendues) [3]

Pour aider le destinataire à identifier la diffusion intermittente et à décider de lire ou non le flux, le diffuseur doit également définir avec précision la structure LTV des métadonnées Streaming_Audio_Context [1].

Identifier les éléments audio qui vous intéressent

Pour signaler de manière dynamique si une diffusion intermittente contient un élément audio intéressant à un moment donné, l'émetteur utilise les structures LTV des métadonnées Audio_Active_State.

  • Métadonnées de niveau 2 de la structure BASE : la valeur 0x01 indique que les BIS d'un sous-groupe contiennent actuellement des éléments audio intéressants.
  • Métadonnées d'annonce de diffusion publique : une valeur de 0x01 indique qu'au moins un des BIS d'un BIG contient un élément audio d'intérêt.

Les valeurs de durée de vie des métadonnées Audio_Active_State doivent être définies sur 0x01 peu de temps avant la transmission de l'audio d'intérêt, ce qui permet à un appareil de balayage de se synchroniser sur une source de diffusion publique. À l'inverse, il doit être défini sur 0x00 peu de temps après la fin de la transmission.

Exploiter le contexte audio en streaming

Fournir un contexte explicite aide le framework Android et les appareils de réception à hiérarchiser les flux entrants. Par exemple, un système de sonorisation peut définir le type Streaming_Audio_Context sur "Instructional" pour permettre aux annonces d'interrompre proprement la lecture de contenu multimédia local d'un récepteur et de la reprendre de manière fluide par la suite.

Références

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