Seguimiento de cabeza a través de audio LE

El audio Bluetooth (BT) de bajo consumo (LE) presenta los mecanismos de transporte lógico asíncrono orientado a la conexión (LE-ACL) y isócrono (LE-ISO) para los datos de seguimiento de cabeza (HT).

Android 15 admite ajustes del modo de latencia para HT según se use el mecanismo de transporte LE-ACL o LE-ISO.

En esta página, se describe cómo interactúan el framework de audio, el HAL de audio y la pila de Bluetooth para descubrir y seleccionar los mecanismos de transporte LE-ACL o LE-ISO compatibles con el host y los auriculares.

Compatibilidad con LE-ACL y LE-ISO

Android 15 incluye compatibilidad con los mecanismos de transporte LE-ACL y LE-ISO mediante una propiedad del sistema definida por el proveedor, modos de latencia de HAL de audio y modos de conexión del espacializador.

Propiedad del sistema

La implementación del proveedor del teléfono enumera los mecanismos de transporte admitidos en la propiedad del sistema bluetooth.core.le.dsa_transport_preference. El valor es una lista de cadenas separadas por comas que enumera los transportes admitidos en orden de preferencia:

  • le-acl: Transporte de LE-ACL, cuando los datos de la unidad de medición inercial (IMU) se informan a través de la pila de sensores.
  • iso-hw: Transporte ISO con capacidad para entubar datos de HT directamente desde el controlador Bluetooth al espacializador en el DSP de audio.
  • iso-sw: Transporte ISO sin capacidad de tunelización, cuando los datos de la IMU se informan a través de la pila de sensores.

Modos de latencia

En el caso del audio BT LE, el mecanismo para que la pila de BT indique los modos de latencia admitidos al HAL de audio y al framework de audio es el mismo que el definido para BT Classic (A2DP). El HAL de audio informa los modos de latencia compatibles según el dispositivo de audio seleccionado actualmente.

Las implementaciones de A2DP solo admiten los modos FREE y LOW_LATENCY.

En cambio, para el audio LE de BT, los siguientes modos de latencia se definen en el HAL de audio para admitir la adición de mecanismos de transporte LE-ACL y LE-ISO:

  • FREE: Este valor indica que no hay una restricción específica en la latencia. Este modo se usa cuando no se admite la latencia baja (lo indica el HAL) o cuando la HT no está activa (lo indica el framework).

  • LOW: Este valor indica una latencia relativamente baja (por ejemplo, inferior a 100 ms) compatible con la operación de HT. Este modo se usa cuando se admite latencia baja y HID se transmite a través del protocolo ACL (lo indica el HAL) o cuando HT está activo y no hay otros modos de latencia baja disponibles (lo indica el framework).

  • DYNAMIC_SPATIAL_AUDIO_SOFTWARE: Este modo se usa cuando se cumple una de las siguientes condiciones:

    • Cuando se admite la latencia baja, HID se transmite a través del protocolo ISO y no se puede establecer un túnel para el motor de efectos de espacialización (que indica el HAL).
    • Cuando HT está activo y se usa el protocolo ISO cuando el framework de audio proporciona los datos HID al motor de efectos de espacialización (indicado por el framework).

    En este modo, la biblioteca de procesamiento de HT en el framework realiza todo el procesamiento previo de los datos de la IMU y la conciliación con los movimientos del teléfono que indican los sensores del teléfono.

  • DYNAMIC_SPATIAL_AUDIO_HARDWARE: Este modo se usa cuando se cumple una de las siguientes condiciones:

    • Cuando se admite la latencia baja, HID se transmite a través del protocolo ISO, y se puede establecer un túnel para el motor de efectos de espacialización (que indica el HAL).
    • Cuando el HT está activo y se usa el protocolo ISO cuando los datos HID se enrutan al motor de efectos de espacialización (indicado por el framework).

    En este modo, el motor de efectos de espacialización recibe los datos de IMU sin procesar directamente desde la pila de BT o el controlador de BT. La implementación del efecto de espacializador realiza todo el procesamiento previo de los datos de la IMU y la conciliación con los movimientos del teléfono que indican los sensores del teléfono.

Las enums de modo de latencia se asignan a la propiedad del sistema bluetooth.core.le.dsa_transport_preference en Spatializer.cpp.

Compatibilidad con el espacializador

El controlador de espacialización en el servicio de política de audio controla la selección del protocolo de transporte de HT sobre audio LE. La implementación del motor de efectos de espacialización indica la compatibilidad con el tunelización de datos de HT con la función HeadTracking.ConnectionMode.

Los modos de conexión de HT compatibles son los siguientes:

  • FRAMEWORK_PROCESSED: El framework de audio proporciona datos de IMU procesados previamente en un formato vectorial de cabeza a escenario a HAL. Este modo predeterminado corresponde al modo actual con BT clásico.
  • DIRECT_TO_SENSOR_SW: El motor de efectos de espacialización se conecta directamente al sensor a través de la pila de software del sensor. El framework de audio solo controla el estado habilitado del sensor. Las implementaciones de software que no usan el procesamiento previo de datos de IMU libheadtracking de AOSP o las implementaciones de espacializador descargadas de DSP pueden usar el modo DIRECT_TO_SENSOR_SW.
  • DIRECT_TO_SENSOR_TUNNEL: El motor de efectos de espacialización se conecta directamente al sensor a través del tunelización de hardware. El framework de audio solo controla el estado habilitado del sensor. Las implementaciones de espacializador descargadas del DSP pueden usar el modo DIRECT_TO_SENSOR_TUNNEL.

Selección del modo de latencia

El framework selecciona un modo de latencia de la lista de modos de latencia compatibles que informa el sistema HAL. El modo de latencia se establece según el estado de habilitación de HT actual, la compatibilidad con el espacializador actual y la propiedad del sistema especificada por el proveedor que establece un orden de prioridad entre los mecanismos de transporte.

El framework usa el siguiente proceso en selectHeadtrackingConnectionMode_l para seleccionar el modo de latencia:

  1. El framework carga la preferencia de transporte desde la propiedad del sistema bluetooth.core.le.dsa_transport_preference.
  2. Los modos de latencia admitidos que informa el HAL de audio se filtran y se ordenan según la lista cargada en el paso 1.
  3. Si el modo de baja latencia de prioridad más alta es iso-hw y la implementación del espacializador admite la conexión directa del sensor (es decir, DIRECT_TO_SENSOR_SW o DIRECT_TO_SENSOR_TUNNEL se configuran en el espacializador), el modo de latencia se establece en DYNAMIC_SPATIAL_AUDIO_HARDWARE.

  4. Si el modo de latencia baja de mayor prioridad es iso-hw y la implementación del espacializador no admite la conexión directa del sensor (DIRECT_TO_SENSOR_SW o DIRECT_TO_SENSOR_TUNNEL no están configurados en el espacializador), el siguiente modo preferido (que es iso-sw o le-acl) determina el modo de latencia (que es DYNAMIC_SPATIAL_AUDIO_SOFTWARE o LOW).

    Si no se especifica el siguiente modo preferido, el sistema informa un error de configuración del producto.