Audio Bluetooth à basse consommation

L'audio Bluetooth à basse consommation (LEA) garantit aux utilisateurs un son haute fidélité sans sacrifier l'autonomie de la batterie, et leur permet de basculer facilement entre différents cas d'utilisation. Android 13 (niveau d'API 33) est compatible avec LEA.

La plupart des casques LEA seront en mode double jusqu'à ce que la part de marché des appareils sources LEA augmente. Les utilisateurs doivent pouvoir associer et configurer les deux transports sur leur casque double mode.

cas d'utilisation

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

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

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

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

• Améliorations de l'échantillonnage audio: le casque permet de maintenir une haute qualité audio en sortie lorsque vous utilisez des micros. Le Bluetooth classique réduit la qualité audio lors de l'utilisation de micros Bluetooth. Avec l'audio BLE, l'échantillonnage des entrées et sorties peut atteindre 32 kHz.

• Micro stéréo: les écouteurs peuvent enregistrer du son grâce à des micros stéréo, ce qui permet d'améliorer le son spatial.

• Compatibilité avec les profils d'aide auditive (HAP) : la technologie HAP offre aux utilisateurs une meilleure accessibilité et une plus grande utilisation par rapport aux protocoles ASHA précédents. Les utilisateurs peuvent utiliser leurs appareils auditifs pour les appels téléphoniques et les applications VoIP.

• Compatibilité avec le protocole d'attributs amélioré (EATT) : le protocole EATT permet aux développeurs d'envoyer plusieurs commandes à la fois aux écouteurs associés.

Scénarios clés

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

1. Conversations: les applications téléphoniques et VoIP qui nécessitent un routage des communications à faible latence offrent un son de haute qualité et sollicitent moins la batterie.

2. Jeux: le micro et la lecture haute fidélité simultanés permettent aux jeux de diffuser un son de haute qualité sur des écouteurs. Une application de jeu vidéo peut accéder à l'entrée audio BLE lorsqu'un jeu active le micro Bluetooth comme étant prêt à être utilisé. Ensuite, lorsqu'un joueur démarre une conversation en direct avec un autre joueur, l'application de jeu peut utiliser immédiatement les données du micro.

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 préféré dans les paramètres du système.

4. Accessibilité: les appareils auditifs compatibles avec l'audio BLE peuvent désormais utiliser le micro, ce qui permet aux utilisateurs d'utiliser leurs appareils auditifs en continu pour passer un appel.

API et méthodes audio BLE

Les API et méthodes suivantes sont requises pour la compatibilité avec les écouteurs audio BLE:

Responsable audio

• setCommunicationDevice() sélectionne l'appareil audio à utiliser pour les cas d'utilisation de communication, 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 appareil audio différent de 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 optimale à l'utilisateur lorsqu'il passe d'une application à une autre.

Profil Bluetooth

• BluetoothLeAudio contrôle le service Bluetooth via un objet proxy.

Service Telecom InCall

• setAudioRoute() définit la route audio vers l'appareil actif actuel.
• CallAudioState.ROUTE_BLUETOOTH dirige le flux audio via le Bluetooth.
• requestBluetoothAudio() demande un routage audio vers un appareil Bluetooth spécifique.

Informations sur l'appareil audio

• AudioDeviceInfo.TYPE_BLE_HEADSET décrit le type d'appareil audio comme un appareil LEA. Permet de déterminer si l'appareil auditif est un appareil LEA.

Enregistreur audio

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

Adaptateur Bluetooth

• isLeAudioSupported() renvoie si le matériel de la plate-forme est compatible avec LEA.
• isLeAudioBroadcastSourceSupported() renvoie si le matériel de la plate-forme est compatible avec LEA.

Guides par cas d'utilisation

Vous trouverez ci-dessous des consignes pour implémenter la LEA selon des cas d'utilisation spécifiques.

Applications de communication vocale

Les applications de communication vocale peuvent gérer le routage audio et l'état des appareils en gérant eux-mêmes leur état ou en utilisant l'API Telecom qui s'occupe du routage audio et de la logique d'état pour vous.

• Autogéré: pour les applications qui utilisent actuellement startBluetoothSco(), stopBluetoothSco() et setSpeakerphoneOn(), ou qui souhaitent gérer eux-mêmes l'état du routage audio, suivez le guide des appels autogérés Audio Manager.

• Géré: utilisez l'API Telecom pour créer une application d'appel audio ou vidéo. Cette API vous permet de contrôler rapidement et facilement le routage audio et de basculer entre les appareils Bluetooth. Pour en savoir plus, consultez le guide des appels gérés par Telecom.

Applications d'enregistrement audio

• Enregistreur multimédia: lorsque vous utilisez l'Enregistreur multimédia, vous pouvez désormais enregistrer en stéréo si l'écouteur Bluetooth est compatible avec la norme LEA. Consultez le Guide de l'enregistrement audio.

Recommandations de casque LE Audio (LEA)

Avec le lancement d'autres casques LEA, nous avons découvert dans les tests en conditions réelles des problèmes 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 pour les utilisateurs Android.

Description	Le contexte
Prise en charge de la dérivation de clés de transport croisé (CTKD) pour les casques à double mode : Prise en charge de la dérivation de clés pour l'association Classic-LE et l'association LE-Classique.	La plupart des nouveaux casques LEA seront en mode double jusqu'à ce que la part de marché des appareils sources LEA augmente. Il est important que les utilisateurs puissent associer facilement leurs casques double mode et configurer les deux transports. Ceci est également important pour Google Fast Pair.
Intégrez 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 aux appareils centraux. Elle sera ajoutée à BT SIG à venir.	Contrairement au modèle de pagination de BR/EDR, où une connexion peut être initiée par le téléphone ou le casque, une connexion dans 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 ne pourra peut-être pas se reconnecter au périphérique sans l'ajouter à une liste d'autorisation. Toutefois, une liste d'autorisation peut empêcher le casque de se connecter à un autre appareil central. Par conséquent, il est important que les casques LEA prennent correctement en charge les TA afin que le dispositif central puisse se reconnecter de manière fiable sans solutions de contournement susceptibles de rompre les connexions multipoints.
Visibilité optimisée pour les écouteurs double mode L'écouteur principal (composant BR/EDR) doit promouvoir son utilisation à l'aide de son adresse publique, permettre les requêtes et l'analyse de page avec son nom disponible via EIR, et définir le bit LE audio 14 sur 1 dans les principales classes de service de la classe d'appareils (CoD). Écouteur principal – Composant LE: l'écouteur principal doit diffuser une annonce connectable et visible (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. La catégorie d'apparence doit correspondre à la catégorie d'apparence correspondant au type d'appareil distant et doit utiliser ces informations pour ajuster ses règles de routage audio et audio. Écouteurs secondaires – LE uniquement: l'écouteur secondaire doit diffuser une annonce connectable et non visible dont la catégorie d'apparence doit être définie sur la catégorie d'apparence appropriée. Celle-ci doit correspondre au type d'appareil distant, en partant du principe que l'appareil central utilisera ces informations pour ajuster son UI et ses règles de routage audio. Les écouteurs doivent désigner de manière dynamique un responsable du groupe CSIP en tant qu'appareil principal. Si l'écouteur est en mode double, l'appareil principal doit être en mode double pour que les fonctionnalités LE et Classic fonctionnent correctement après l'association.	Cela empêche les écouteurs LEA à double mode d'apparaître sous forme d'entrées en double dans les paramètres Bluetooth, ce qui pourrait perturber les utilisateurs et compromettre l'expérience d'association LEA. L'élection du responsable dynamique est particulièrement importante pour les appareils à double mode associés de manière incrémentielle. Par exemple, si un seul écouteur est disponible lors de l'association initiale, il doit se présenter comme un appareil double mode. Lorsque l'utilisateur associe l'écouteur avec le deuxième écouteur par la suite, il lui suffit de l'associer au composant LE. CSIP s'assure alors 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é.
Ils sont compatibles avec le protocole EATT (Enhanced Attribute Protocol).	Réduit la latence d'association et de connexion.
Prise en charge de la mise en cache robuste de GATT.	Réduit la latence de connexion, en particulier pour les écouteurs TWS.
Prenez en charge le sous-classement de connexion.	Permet une planification plus flexible des paquets et une économie potentielle de la batterie.
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 accepter les fréquences plus élevées.	Tirez parti des taux d'échantillonnage plus élevés compatibles avec les chemins d'appel LEA ou les chemins de capture VoIP, et la lecture de contenus multimédias.
Assurer la compatibilité avec LE Power Control	Meilleure gestion de l'alimentation

Prise en charge des types de contexte

Description	Le contexte
Utilisez tous les types de contexte spécifiés dans la section Numéros attribués 6.12.3, sauf si le casque n'est pas explicitement compatible avec un type de contexte donné.	Par exemple, si le type de contexte "Jeu" n'est pas compatible, Android envoie des sons de jeu. Notez en particulier que le type de contexte "Non spécifié" ne signifie pas "aucun type de contexte" et qu'il ne couvre pas les types de contexte non compatibles.
Lorsque l'appareil central interagit avec le serveur ASCS du périphérique, celui-ci doit se connecter aux serveurs MCS et TBS de l'appareil central. L'appareil central n'utilise pas toujours LE Audio comme route de streaming, car il peut avoir recours à A2DP ou HFP. Le périphérique peut utiliser une interaction ASCS pour indiquer si l'appareil central utilisera LE Audio pour le streaming. La lecture, l'écriture et l'enregistrement pour les notifications sont des exemples d'interactions ASCS.