Audio Bluetooth à basse consommation

L'audio Bluetooth à basse consommation (LEA) garantit aux utilisateurs un son haute fidélité sans compromettre 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 leurs casques à double mode.

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 avec un ou plusieurs appareils 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 accédant à des diffusions publiques à des fins d'information, de divertissement ou d'accessibilité.

• 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 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 lorsque vous utilisez des micros. Le mode Bluetooth classique réduit la qualité audio lors de l'utilisation de micros Bluetooth. Avec l'audio BLE, l'échantillonnage d'entrée et de sortie peut atteindre 32 kHz.

• Micro stéréo: les appareils auditifs peuvent enregistrer du son avec des micros stéréo pour améliorer le son spatial.

• Prise en charge des profils d'appareils auditifs (HAP) : le mode HAP offre aux utilisateurs une meilleure accessibilité et une meilleure utilisation que les 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 EATT (Enhanced Attribute Protocol) : le protocole EATT permet aux développeurs d'envoyer plusieurs commandes à la fois à des écouteurs associés.

Scénarios clés

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

1. Conversationnelle: les applications de téléphonie et de VoIP qui nécessitent un routage de communication à faible latence offrent un son de haute qualité et sollicitent moins la batterie.

2. Jeux vidéo: l'utilisation simultanée d'un micro et d'une lecture haute fidélité permet aux jeux de diffuser en streaming un son 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 à l'emploi. Ensuite, lorsqu'un joueur entame une conversation en direct avec un pair, l'application de jeu peut utiliser les données du micro immédiatement.

3. Multimédia: les applications multimédias sont autorisées à définir l'appareil par défaut du gestionnaire audio. L'utilisateur peut modifier ce paramètre en modifiant son appareil préféré dans les paramètres 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 un appel.

API et méthodes audio BLE

Les API et méthodes suivantes sont requises pour prendre en charge les écouteurs audio BLE:

Gestionnaire audio

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

Profil Bluetooth

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

Service Telecom InCall

• setAudioRoute() définit l'itinéraire audio vers l'appareil actif actuel.
• CallAudioState.ROUTE_BLUETOOTH dirige le flux audio via le Bluetooth.
• requestBluetoothAudio() demande le 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 étant un appareil LEA. Permet de déterminer si l'appareil auditif est de type LEA.

Enregistreur audio

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

Adaptateur Bluetooth

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

Guides basés sur le cas d'utilisation

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

Applications de communication vocale

Les applications de communication vocale peuvent choisir de gérer le routage audio et l'état de l'appareil en gérant automatiquement leur état ou en utilisant l'API Telecom qui gère le routage audio et la logique d'état à votre place.

• Autogéré: pour les applications qui utilisent actuellement startBluetoothSco(), stopBluetoothSco() et setSpeakerphoneOn() ou si vous souhaitez gérer vous-même l'état du routage audio, suivez le guide d'autogestion d'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 le basculement entre Appareils Bluetooth Pour en savoir plus, consultez les Guide sur les appels gérés par les télécommunications

Applications d'enregistrement audio

• Enregistreur multimédia: lors d'un enregistrement audio avec Media Recorder, vous pouvez désormais enregistrer en stéréo si l'audio Bluetooth est compatible avec la technologie LEA. Consultez le Guide des enregistrements audio.

Recommandations de casque LE Audio (LEA)

Alors que de plus en plus de casques LEA sont commercialisés, nous avons découvert des problèmes dans le monde réel qui dégradent l'expérience utilisateur. La spécification ne couvre pas tous de ces problèmes. Le tableau suivant fournit une liste de recommandations Les fabricants de casques LEA doivent suivre pour améliorer l'expérience de bout en bout pour Utilisateurs d'Android

Description	Contexte
Prise en charge de la dérivation de clés de transport croisées (CTKD) pour Casques double mode: <ph type="x-smartling-placeholder"> </ph> Prise en charge de la dérivation des clés pour l'association classique/LE et Association de LE-à-Classic.	La plupart des nouveaux casques LEA seront en double mode jusqu'à ce que l'appareil source LEA des parts de marché augmentent. Il est important que les utilisateurs puissent associer leurs des casques bi-mode de manière fluide et de configurer les deux transports. C'est également important pour l'Association express Google.
Prenez en charge les annonces ciblées si vous le souhaitez. vos casques LEA pour se reconnecter aux appareils sources de manière fiable. Les écouteurs LE Audio doivent utiliser des TA pour demander une connexion entrante des appareils centraux. Sera ajouté au prochain 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 en LEA doit être initiée par le dispositif central. Actuellement, de nombreux casques TA, ce qui signifie que le dispositif central pourrait ne pas être en mesure de se reconnecter au périphérique sans l'ajouter à une liste d'autorisation. Toutefois, une solution de contournement peut empêcher le casque se connectant à un autre appareil central. Il est donc important pour que les casques LEA prennent correctement en charge les TA afin que l'appareil central peut se reconnecter de manière fiable sans recourir à des solutions des connexions multipoints.
Visibilité optimisée pour les écouteurs à double mode <ph type="x-smartling-placeholder"> </ph> L'écouteur principal – Composant BR/EDR doit faire l'objet d'une annonce. à l'aide de son adresse publique, et de permettre l'envoi de requêtes et l'analyse de pages disponible via EIR, et définissez le bit LE Audio sur 14 sur 1 dans la Classes de services majeures de la classe d'appareil (CoD). Écouteur principal – Composant LE: écouteur principal doit réaliser une opération "Connectable" et "Visible" (limitée ou (général) annonce utilisant la même adresse publique que le BR/EDR et le même nom local complet que le BR/EDR et sa catégorie d'apparence définie Catégorie d'apparence correspondant au type d'appareil distant l’attente que l’appareil central utilise ces informations pour ajuster ses règles d'UI et de routage audio. Écouteur secondaire – LE uniquement: écouteur secondaire doit diffuser une publicité connectable et non visible avec sa catégorie d'apparence définie comme une catégorie d'apparence appropriée ; qui correspond au type d'appareil distant, en partant du principe que l'appareil central utilisera ces informations pour ajuster son UI et règles de routage audio Les écouteurs doivent sélectionner dynamiquement un responsable du CSIP. comme appareil principal. Si l'écouteur est en mode double, l'appareil principal doit être en mode double pour garantir que les versions LE et Classic fonctionnent correctement après l'association.	Cela permet d'éviter que des écouteurs LEA double mode apparaissent comme doublons entrées dans les paramètres Bluetooth, ce qui peut perturber les utilisateurs et compromettre l'expérience d'association LEA. L'élection des leaders dynamiques est particulièrement importante pour les modes doubles appareils qui sont 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 appareil à double mode. Lorsqu'un utilisateur s'associe plus tard au deuxième écouteur, il suffit de les associer au composant LE, et le CSIP s'assure elles sont regroupées sur Android. L'adresse d'identité est recommandée lors de l'association, car le BR/EDR expose déjà l'adresse publique de l'appareil aux appareils à proximité appareils.
Compatibilité avec le protocole EATT (Enhanced Attribute Protocol)	Réduit la latence d'association et de connexion.
Prise en charge de la mise en cache GATT robuste.	Réduit la latence de connexion, en particulier pour les écouteurs TWS.
Prenez en charge le sous-classement des connexions.	Planification plus flexible des paquets et autonomie potentielle d'économies.
Lors du prétraitement et du post-traitement, assurez-vous que la capture, le pipeline de traitement du signal peut fonctionner à 16, 24, 32 et 48 kHz, et la compatibilité avec les fréquences les plus élevées.	Profiter des taux d'échantillonnage plus élevés acceptés pour les appels LEA les chemins de capture et la lecture des contenus multimédias.
Assurer la 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 Numéros attribués 6.12.3 sauf si le casque ne prend pas explicitement en charge un type de contexte donné.	Par exemple, si le contexte est défini sur "Jeu", n'est pas prise en charge, alors Android envoie les sons du jeu. Notez en particulier que la colonne "Non spécifié" le contexte ne signifie pas "tout type de contexte" et ne couvre pas de contexte.
Lorsque le périphérique central interagit avec ASCS du périphérique périphérique, le périphérique doit se connecter au MCS et TBS du dispositif central. L'appareil central n'utilise pas toujours LE Audio pour diffuser car il pourrait revenir à l'utilisation d'A2DP ou de HFP. Le périphérique peut utiliser l'interaction ASCS pour indiquer si le système l'appareil utilisera LE Audio pour le streaming. Quelques exemples d'interactions ASCS sont la lecture, l'écriture et l'enregistrement pour .