Suivi des mouvements de la tête avec LE Audio

L'audio Bluetooth (BT) à basse consommation (LE) présente les mécanismes de transport logique LE-ACL (Asynchronous Connection-Oriented Logical) et Isochronous (LE-ISO) à basse consommation pour le suivi de la tête (HT).

Android 15 prend en charge les ajustements du mode de latence pour le HT en fonction de l'utilisation du mécanisme de transport LE-ACL ou LE-ISO.

Cette page décrit comment le framework audio, le 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, des modes de latence de l'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 indique les transports compatibles dans l'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 la possibilité de tunneliser les données HT directement depuis le contrôleur Bluetooth vers le spatialisateur du DSP audio.
  • iso-sw: transport ISO sans fonctionnalité de tunnelisation, lorsque les données de l'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 BT Classic (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 Bluetooth LE, les modes de latence suivants sont définis dans le HAL audio pour prendre en charge l'ajout de mécanismes de transport LE-ACL et LE-ISO:

  • FREE: cette valeur indique qu'aucune contrainte spécifique ne s'applique à la latence. Ce mode est utilisé lorsque la faible latence n'est pas prise en charge (indiqué par le HAL) ou lorsque la technologie HT n'est pas active (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 l'HID est transmis via le protocole ACL (indiqué par le HAL), ou lorsque la technologie HT est active 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, HID est transmis via le protocole ISO, et HID ne peut pas être mis en tunnel vers le moteur d'effet spatialisateur (indiqué par le HAL).
    • Lorsque le HT est actif et que le protocole ISO est utilisé, le framework audio fournit les données HID au moteur d'effet spatialisateur (indiqué par le framework).

    Dans ce mode, la bibliothèque de calcul HT du framework effectue le prétraitement des données de l'IMU et le rapprochement avec les mouvements du téléphone indiqués par les capteurs de 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, HID est transmis via le protocole ISO, et HID peut être mis en tunnel vers le moteur d'effet spatialisateur (indiqué par le HAL).
    • Lorsque le protocole HT est activé et le protocole ISO est utilisé lorsque les données HID sont acheminées par tunnel vers le moteur d'effet spatialisé (indiqué par le framework).

    Dans ce mode, le moteur d'effet de spatialisation reçoit les données de la centrale inertielle non traitées directement depuis la pile ou le contrôleur BT. L'implémentation de l'effet spatialisant effectue tous les prétraitements sur les données de l'IMU et effectue le rapprochement avec les mouvements de téléphone indiqués par les capteurs de téléphone.

Les énumérations de mode de latence sont mappées sur la propriété système bluetooth.core.le.dsa_transport_preference dans Spatializer.cpp.

Compatibilité avec la fonctionnalité Spatializer

Le contrôleur de spatialisation du service de stratégie audio contrôle la sélection du protocole de transport HT sur l'audio LE. L'implémentation du moteur d'effet spatialisateur indique la prise en charge du tunnellisation 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 dans un format de vecteur de tête à étape à HAL. Ce mode par défaut correspond au mode actuel avec BT Classic.
  • DIRECT_TO_SENSOR_SW: le moteur d'effet spatialisé se connecte directement au capteur via la pile logicielle. Le framework audio ne contrôle que l'état d'activation du capteur. Les implémentations logicielles qui n'utilisent pas le prétraitement des données IMU libheadtracking AOSP ou les implémentations de spatialiseur offloadées par DSP peuvent utiliser le mode DIRECT_TO_SENSOR_SW.
  • DIRECT_TO_SENSOR_TUNNEL: le moteur d'effet spatialisé se connecte directement au capteur via la tunnelisation matérielle. Le framework audio ne contrôle que l'état d'activation du capteur. Les implémentations de spatialiseur offloadées par 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 le HAL. Le mode de latence est défini en fonction de l'état d'activation actuel du HT, de la compatibilité actuelle avec le 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:

  1. Le framework charge la préférence de transport à partir de la propriété système bluetooth.core.le.dsa_transport_preference.
  2. Les modes de latence compatibles signalés par le HAL audio sont filtrés et triés en fonction de la liste chargée à l'étape 1.
  3. 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.
  4. Si le mode à faible latence ayant la priorité la plus élevée est iso-hw et que l'implémentation de la spatialisation n'est pas compatible avec la connexion directe des capteurs (DIRECT_TO_SENSOR_SW ou DIRECT_TO_SENSOR_TUNNEL n'est pas défini 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.