Le Bluetooth (BT) à basse consommation (LE) Audio introduit les mécanismes de transport logique asynchrone orienté connexion (LE-ACL) et isochrone (LE-ISO) pour les données de suivi de la tête (HT).
Android 15 permet d'ajuster le mode de latence pour le suivi de la tête en fonction du mécanisme de transport LE-ACL ou LE-ISO utilisé.
Cette page explique comment le framework audio, l'interface HAL audio et la pile Bluetooth interagissent pour découvrir et sélectionner les mécanismes de transport LE-ACL ou LE-ISO compatibles avec l'hôte et le casque.
Compatibilité avec LE-ACL et LE-ISO
Android 15 est compatible avec les mécanismes de transport LE-ACL et LE-ISO à l'aide d'une propriété système définie par le fournisseur , de modes de latence HAL audio , et de modes de connexion spatialiseur .
Propriété système
L'implémentation du fournisseur de téléphone répertorie les mécanismes de transport compatibles dans la
bluetooth.core.le.dsa_transport_preference propriété système. La valeur est une liste de chaînes séparées par des virgules,
qui répertorie les transports compatibles par ordre de préférence :
le-acl: transport LE-ACL, lorsque les données de l'unité de mesure inertielle (UMI) sont signalées via la pile de capteurs.iso-hw: transport ISO avec possibilité de tunneliser les données de suivi de la tête directement du contrôleur Bluetooth au spatialiseur dans le DSP audio.iso-sw: transport ISO sans possibilité de tunnelisation, lorsque les données de l'UMI sont signalées via la pile de capteurs.
Modes de latence
Dans le cas du Bluetooth LE Audio, le mécanisme permettant à la pile Bluetooth d'indiquer les modes de latence compatibles à l'interface HAL audio et au framework audio est le même que celui défini pour le Bluetooth Classic (A2DP). L'interface HAL audio signale les modes de latence compatibles en fonction de l'appareil audio actuellement sélectionné.
Les implémentations A2DP ne sont compatibles qu'avec les modes FREE et LOW_LATENCY.
En revanche, pour le Bluetooth LE Audio, les modes de latence suivants sont définis dans l'interface HAL audio pour prendre en charge l'ajout de mécanismes de transport LE-ACL et LE-ISO :
FREE: cette valeur indique qu'il n'existe aucune contrainte spécifique concernant la latence. Ce mode est utilisé lorsque la faible latence n'est pas compatible (indiquée par l'interface HAL) ou lorsque le suivi de la tête n'est pas actif (indiqué par le framework).LOW: cette valeur indique une latence relativement faible (par exemple, inférieure à 100 ms) compatible avec le fonctionnement du suivi de la tête. Ce mode est utilisé lorsque la faible latence est compatible et que l'interface HID est transmise via le protocole ACL (indiqué par l'interface HAL), ou lorsque le suivi de la tête est actif et qu'aucun autre mode de faible latence n'est disponible (indiqué par le framework).DYNAMIC_SPATIAL_AUDIO_SOFTWARE: ce mode est utilisé lorsque l'une des conditions suivantes est remplie :- Lorsque la faible latence est compatible, l'interface HID est transmise via le protocole ISO et ne peut pas être tunnelisée vers le moteur d'effets spatialiseur (indiqué par l'interface HAL).
- Lorsque le suivi de la tête est actif et que le protocole ISO est utilisé lorsque le framework audio fournit les données HID au moteur d'effets spatialiseur (indiqué par le framework).
Dans ce mode, la bibliothèque de calcul du suivi de la tête dans le framework effectue tout le prétraitement des données de l'UMI et le rapprochement avec les mouvements du téléphone indiqués par les capteurs du téléphone.
DYNAMIC_SPATIAL_AUDIO_HARDWARE: ce mode est utilisé lorsque l'une des conditions suivantes est remplie :- Lorsque la faible latence est compatible, l'interface HID est transmise via le protocole ISO et peut être tunnelisée vers le moteur d'effets spatialiseur (indiqué par l'interface HAL).
- Lorsque le suivi de la tête est actif et que le protocole ISO est utilisé lorsque les données HID sont tunnelisées vers le moteur d'effets spatialiseur (indiqué par le framework).
Dans ce mode, le moteur d'effets spatialiseur reçoit les données UMI brutes directement de la pile Bluetooth ou du contrôleur Bluetooth. L'implémentation de l'effet spatialiseur effectue tout le prétraitement des données de l'UMI et la réconciliation avec les mouvements du téléphone indiqués par les capteurs du téléphone.
Les énumérations du mode de latence sont mappées à la bluetooth.core.le.dsa_transport_preference
propriété système dans Spatializer.cpp.
Compatibilité avec le spatialiseur
Le contrôleur
de spatialiseur du service de règles audio contrôle la sélection du protocole de transport du suivi de la tête via le Bluetooth LE Audio. L'implémentation du moteur d'effets spatialiseur indique
la compatibilité avec la tunnelisation des données de suivi de la tête grâce à la HeadTracking.ConnectionMode fonctionnalité.
Les modes de connexion du suivi de la tête compatibles sont les suivants :
FRAMEWORK_PROCESSED: le framework audio fournit des données UMI prétraitées au format vectoriel de la tête à la scène à l'interface HAL. Ce mode par défaut correspond au mode actuel avec le Bluetooth Classic.DIRECT_TO_SENSOR_SW: le moteur d'effets spatialiseur se connecte directement au capteur via la pile logicielle du capteur. Le framework audio ne contrôle que l'état activé du capteur. Les implémentations logicielles qui n'utilisent pas le prétraitement des données UMI AOSPlibheadtrackingni les implémentations de spatialiseur déchargées par le DSP peuvent utiliser le modeDIRECT_TO_SENSOR_SW.DIRECT_TO_SENSOR_TUNNEL: le moteur d'effets spatialiseur se connecte directement au capteur via la tunnelisation matérielle. Le framework audio ne contrôle que l'état activé du capteur. Les implémentations de spatialiseur déchargées par le DSP peuvent utiliser le modeDIRECT_TO_SENSOR_TUNNEL.
Sélection du mode de latence
Le framework sélectionne un mode de latence dans la liste des modes de latence compatibles signalés par l'interface HAL. Le mode de latence est défini en fonction de l'état actuel d'activation du suivi de la tête, de la compatibilité actuelle du spatialiseur, et de la propriété système spécifiée par le fournisseur qui établit un ordre de priorité entre les mécanismes de transport.
Le framework utilise le processus suivant dans selectHeadtrackingConnectionMode_l
pour sélectionner le mode de latence :
- Le framework charge la préférence de transport à partir de la
bluetooth.core.le.dsa_transport_preferencepropriété système. - Les modes de latence compatibles signalés par l'interface HAL audio sont filtrés et classés par rapport à la liste chargée à l'étape 1.
- Si le mode de faible latence le plus prioritaire est
iso-hwet que l'implémentation du spatialiseur est compatible avec la connexion directe au capteur (c'est-à-dire queDIRECT_TO_SENSOR_SWouDIRECT_TO_SENSOR_TUNNELsont définis dans le spatialiseur), le mode de latence est défini surDYNAMIC_SPATIAL_AUDIO_HARDWARE. Si le mode de faible latence le plus prioritaire est
iso-hwet que l'implémentation du spatialiseur n'est pas compatible avec la connexion directe au capteur (DIRECT_TO_SENSOR_SWouDIRECT_TO_SENSOR_TUNNELne sont pas définis dans le spatialiseur), le mode préféré suivant (qui estiso-swoule-acl) détermine le mode de latence (qui estDYNAMIC_SPATIAL_AUDIO_SOFTWAREouLOW).Si le mode préféré suivant n'est pas spécifié, le système signale une erreur de configuration du produit.