Head tracking over LE audio

Bluetooth (BT) Low Energy (LE) audio introduces the Asynchronous Connection-oriented Logical (LE-ACL) and Isochronous (LE-ISO) logical transport mechanisms for head tracking (HT) data.

Android 15 provides support for latency mode adjustments for HT based on whether the LE-ACL or LE-ISO transport mechanism is used.

This page describes how the audio framework, audio HAL, and Bluetooth stack interact to discover and select the LE-ACL or LE-ISO transport mechanisms supported by the host and the headset.

Support for LE-ACL and LE-ISO

Android 15 includes support for LE-ACL and LE-ISO transport mechanisms by using a vendor-defined system property, audio HAL latency modes, and spatializer connection modes.

System property

The phone vendor implementation lists the supported transport mechanisms in the bluetooth.core.le.dsa_transport_preference system property. The value is a comma-separated list of strings, listing the supported transports in the order of preference:

  • le-acl: LE-ACL transport, when the inertial measurement unit (IMU) data is reported through the sensor stack.
  • iso-hw: ISO transport with capability to tunnel HT data directly from the Bluetooth controller to the spatializer in the audio DSP.
  • iso-sw: ISO transport without tunneling capability, when the IMU data is reported through the sensor stack.

Latency modes

In the case of BT LE audio, the mechanism for the BT stack to indicate the supported latency modes to the audio HAL and audio framework is the same as that defined for BT Classic (A2DP). The audio HAL reports the supported latency modes according to the currently selected audio device.

A2DP implementations support only FREE and LOW_LATENCY modes.

In contrast, for BT LE audio, the following latency modes are defined in the audio HAL to support the addition of LE-ACL and LE-ISO transport mechanisms:

  • FREE: This value indicates that there's no specific constraint on the latency. This mode is used when low latency isn't supported (indicated by the HAL), or when HT isn't active (indicated by the framework).

  • LOW: This value indicates a relatively low latency (such as, less than 100 ms) compatible with HT operation. This mode is used when low latency is supported and HID is conveyed over the ACL protocol (indicated by the HAL), or when HT is active and no other low latency modes are available (indicated by the framework).

  • DYNAMIC_SPATIAL_AUDIO_SOFTWARE: This mode is used when one of the following conditions are met:

    • When low latency is supported, HID is conveyed over the ISO protocol, and HID can't be tunneled to the spatializer effect engine (indicated by the HAL).
    • When HT is active and the ISO protocol is used when the audio framework provides the HID data to the spatializer effect engine (indicated by the framework).

    In this mode, the HT computing library in the framework does all the preprocessing on the IMU data and reconciliation with phone movements indicated by phone sensors.

  • DYNAMIC_SPATIAL_AUDIO_HARDWARE: This mode is used when one of the following conditions are met:

    • When low latency is supported, HID is conveyed over the ISO protocol, and HID can be tunneled to the spatializer effect engine (indicated by the HAL).
    • When the HT active and the ISO protocol is used when the HID data is tunneled to the spatializer effect engine (indicated by the framework).

    In this mode, the spatializer effect engine receives the unprocessed IMU data directly from the BT stack or BT controller. The spatializer effect implementation does all the preprocessing on the IMU data and reconciliation with phone movements indicated by phone sensors.

The latency mode enums are mapped to the bluetooth.core.le.dsa_transport_preference system property in Spatializer.cpp.

Spatializer support

The spatializer controller in the audio policy service controls the selection of HT transport protocol over LE audio. The spatializer effect engine implementation indicates support for HT data tunneling with the HeadTracking.ConnectionMode capability.

The supported HT connection modes are as follows:

  • FRAMEWORK_PROCESSED: The audio framework provides preprocessed IMU data in a head-to-stage vector format to HAL. This default mode corresponds to current mode with BT classic.
  • DIRECT_TO_SENSOR_SW: The spatializer effect engine directly connects to the sensor through the sensor software stack. The audio framework controls only the enabled state of the sensor. Software implementations that don't use the AOSP libheadtracking IMU data preprocessing or DSP offloaded spatializer implementations can use the DIRECT_TO_SENSOR_SW mode.
  • DIRECT_TO_SENSOR_TUNNEL: The spatializer effect engine directly connects to the sensor through hardware tunneling. The audio framework controls only the enabled state of the sensor. DSP offloaded spatializer implementations can use the DIRECT_TO_SENSOR_TUNNEL mode.

Latency mode selection

The framework selects a latency mode from the list of supported latency modes that are reported by the HAL. The latency mode is set based on the current HT enable state, current spatializer support, and the vendor-specified system property that establishes a priority order between transport mechanisms.

The framework uses the following process in selectHeadtrackingConnectionMode_l to select the latency mode:

  1. The framework loads the transport preference from the bluetooth.core.le.dsa_transport_preference system property.
  2. The supported latency modes reported by the audio HAL are filtered and ordered against the list loaded in step 1.
  3. If the highest priority low latency mode is iso-hw and the spatializer implementation supports direct sensor connection (that is, DIRECT_TO_SENSOR_SW or DIRECT_TO_SENSOR_TUNNEL are set in the spatializer), the latency mode is set to DYNAMIC_SPATIAL_AUDIO_HARDWARE.
  4. If the highest priority low latency mode is iso-hw and the spatializer implementation doesn't support direct sensor connection (DIRECT_TO_SENSOR_SW or DIRECT_TO_SENSOR_TUNNEL aren't set in the spatializer), the next preferred mode (which is either iso-sw or le-acl) determines the latency mode (which is either DYNAMIC_SPATIAL_AUDIO_SOFTWARE or LOW).

    If the next preferred mode isn't specified, the system reports a product configuration error.