À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Suivi de la tête via LE Audio

L'audio Bluetooth (BT) Low Energy (LE) introduit les mécanismes de transport logique Asynchronous Connection-oriented Logical (LE-ACL) et Isochronous (LE-ISO) pour les données de suivi de la tête (HT).

Android 15 permet d'ajuster le mode de latence pour HT en fonction du mécanisme de transport LE-ACL ou LE-ISO utilisé.

Cette page décrit comment le framework audio, l'audio HAL et la pile Bluetooth interagissent pour découvrir et sélectionner les mécanismes de transport LE-ACL ou LE-ISO pris en charge par l'hôte et le casque.

Compatibilité avec LE-ACL et LE-ISO

Android 15 inclut la prise en charge des mécanismes de transport LE-ACL et LE-ISO à l'aide d'une propriété système définie par le fournisseur, des modes de latence HAL audio et des modes de connexion du spatialiseur.

Propriété système

L'implémentation du fournisseur de téléphone liste les mécanismes de transport compatibles dans la propriété système bluetooth.core.le.dsa_transport_preference. La valeur est une liste de chaînes séparées par une virgule, qui répertorie les transports acceptés par ordre de préférence :

le-acl : transport LE-ACL, lorsque les données de l'unité de mesure inertielle (IMU) sont signalées via la pile de capteurs.
iso-hw : transport ISO avec possibilité de transférer les données HT directement du contrôleur Bluetooth au spatialiseur dans le DSP audio.
iso-sw : transport ISO sans capacité de tunneling, lorsque les données IMU sont signalées via la pile de capteurs.

Modes de latence

Dans le cas de l'audio BT LE, le mécanisme permettant à la pile BT d'indiquer les modes de latence compatibles au HAL audio et au framework audio est le même que celui défini pour le BT classique (A2DP). Le HAL audio indique 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 l'audio BT LE, les modes de latence suivants sont définis dans l'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'y a pas de contrainte spécifique sur la latence. Ce mode est utilisé lorsque la faible latence n'est pas prise en charge (indiquée par le HAL) ou lorsque HT 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 HT. Ce mode est utilisé lorsque la faible latence est prise en charge et que le HID est transmis via le protocole ACL (indiqué par le HAL), ou lorsque HT est actif et qu'aucun autre mode à 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 prise en charge, le HID est transmis via le protocole ISO et ne peut pas être tunnelé vers le moteur d'effets spatialiseur (indiqué par le HAL).
- Lorsque HT est actif et que le protocole ISO est utilisé lorsque le framework audio fournit les données HID au moteur d'effet spatialiseur (indiqué par le framework).
Dans ce mode, la bibliothèque de calcul HT du framework effectue tout le prétraitement des données IMU et la réconciliation 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 prise en charge, le HID est transmis via le protocole ISO et peut être tunnelé vers le moteur d'effets spatialiseur (indiqué par le HAL).
- Lorsque le HT est actif et que le protocole ISO est utilisé, les données HID sont tunnelées vers le moteur d'effets spatialiseur (indiqué par le framework).
Dans ce mode, le moteur d'effet spatialisateur reçoit les données IMU brutes directement de la pile ou du contrôleur Bluetooth. L'implémentation de l'effet de spatialisation effectue tout le prétraitement sur les données IMU 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 propriété système bluetooth.core.le.dsa_transport_preference dans Spatializer.cpp.

Compatibilité avec le spatialiseur

Le contrôleur spatializer du service de règles audio contrôle la sélection du protocole de transport HT sur LE Audio. L'implémentation du moteur d'effet spatialiseur indique la prise en charge du tunneling de données HT avec la fonctionnalité HeadTracking.ConnectionMode.

Les modes de connexion HT compatibles sont les suivants :

FRAMEWORK_PROCESSED : le framework audio fournit des données IMU prétraitées au format vectoriel tête-scène à HAL. Ce mode par défaut correspond au mode actuel avec le Bluetooth classique.
DIRECT_TO_SENSOR_SW : le moteur d'effets du 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 IMU libheadtracking AOSP ni les implémentations de spatialiseur déchargées sur le DSP peuvent utiliser le mode DIRECT_TO_SENSOR_SW.
DIRECT_TO_SENSOR_TUNNEL : le moteur d'effet spatialiseur se connecte directement au capteur via le tunneling matériel. Le framework audio ne contrôle que l'état activé du capteur. Les implémentations de spatialiseur déchargées sur le DSP peuvent utiliser le mode DIRECT_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 la HAL. Le mode Latence est défini en fonction de l'état actuel de l'activation HT, de la prise en charge 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 propriété système bluetooth.core.le.dsa_transport_preference.
Les modes de latence compatibles signalés par l'HAL audio sont filtrés et classés par rapport à la liste chargée à l'étape 1.
Si le mode à faible latence de priorité la plus élevée est iso-hw et que l'implémentation du spatialiseur prend en charge la connexion directe des capteurs (c'est-à-dire que DIRECT_TO_SENSOR_SW ou DIRECT_TO_SENSOR_TUNNEL sont définis dans le spatialiseur), le mode de latence est défini sur DYNAMIC_SPATIAL_AUDIO_HARDWARE.
Si le mode à faible latence de priorité la plus élevée est iso-hw et que l'implémentation du spatialiseur ne prend pas en charge la connexion directe des capteurs (DIRECT_TO_SENSOR_SW ou DIRECT_TO_SENSOR_TUNNEL ne sont pas définis dans le spatialiseur), le mode préféré suivant (iso-sw ou le-acl) détermine le mode de latence (DYNAMIC_SPATIAL_AUDIO_SOFTWARE ou LOW).

Si le mode préféré suivant n'est pas spécifié, le système signale une erreur de configuration du produit.