2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
LE 오디오를 통한 헤드 트래킹
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
블루투스 (BT) 저전력 (LE) 오디오에서는 헤드 추적 (HT) 데이터를 위한 비동기 연결 지향 로직(LE-ACL) 및 아이소크로노스 (LE-ISO) 로직 전송 메커니즘을 도입합니다.
Android 15는 LE-ACL 또는 LE-ISO 전송 메커니즘 사용 여부에 따라 HT의 지연 시간 모드 조정을 지원합니다.
이 페이지에서는 오디오 프레임워크, 오디오 HAL, 블루투스 스택이 상호작용하여 호스트와 헤드셋에서 지원하는 LE-ACL 또는 LE-ISO 전송 메커니즘을 검색하고 선택하는 방법을 설명합니다.
LE-ACL 및 LE-ISO 지원
Android 15에는 공급업체 정의 시스템 속성, 오디오 HAL 지연 시간 모드, 스페이셜라이저 연결 모드를 사용하여 LE-ACL 및 LE-ISO 전송 메커니즘을 지원하는 기능이 포함되어 있습니다.
시스템 속성
휴대전화 공급업체 구현은 bluetooth.core.le.dsa_transport_preference
시스템 속성에 지원되는 전송 메커니즘을 나열합니다. 값은 선호도 순으로 지원되는 전송을 나열하는 쉼표로 구분된 문자열 목록입니다.
le-acl
: LE-ACL 전송: 관성 측정 장치 (IMU) 데이터가 센서 스택을 통해 보고되는 경우
iso-hw
: 블루투스 컨트롤러에서 오디오 DSP의 스페이셜라이저로 HT 데이터를 직접 터널링할 수 있는 기능이 있는 ISO 전송입니다.
iso-sw
: IMU 데이터가 센서 스택을 통해 보고되는 경우 터널링 기능이 없는 ISO 전송입니다.
지연 시간 모드
BT LE 오디오의 경우 BT 스택이 오디오 HAL 및 오디오 프레임워크에 지원되는 지연 시간 모드를 표시하는 메커니즘은 BT Classic (A2DP)에 정의된 메커니즘과 동일합니다. 오디오 HAL은 현재 선택된 오디오 기기에 따라 지원되는 지연 시간 모드를 보고합니다.
A2DP 구현은 FREE
및 LOW_LATENCY
모드만 지원합니다.
반면 BT LE 오디오의 경우 LE-ACL 및 LE-ISO 전송 메커니즘 추가를 지원하기 위해 오디오 HAL에 다음과 같은 지연 시간 모드가 정의됩니다.
FREE
: 이 값은 지연 시간에 특정 제약 조건이 없음을 나타냅니다. 이 모드는 저지연이 지원되지 않는 경우 (HAL로 표시됨) 또는 HT가 활성 상태가 아닌 경우 (프레임워크로 표시됨) 사용됩니다.
LOW
: 이 값은 HT 작업과 호환되는 비교적 낮은 지연 시간 (예: 100밀리초 미만)을 나타냅니다. 이 모드는 저지연이 지원되고 HID가 ACL 프로토콜을 통해 전달되는 경우 (HAL로 표시됨) 또는 HT가 활성 상태이고 다른 저지연 모드를 사용할 수 없는 경우(프레임워크로 표시됨) 사용됩니다.
DYNAMIC_SPATIAL_AUDIO_SOFTWARE
: 이 모드는 다음 조건 중 하나가 충족될 때 사용됩니다.
- 지연 시간이 짧은 경우 HID가 ISO 프로토콜을 통해 전달되며 HID를 스페이셜라이저 효과 엔진 (HAL로 표시됨)으로 터널링할 수 없습니다.
- HT가 활성 상태이고 오디오 프레임워크가 스페이셜라이저 효과 엔진에 HID 데이터를 제공할 때 ISO 프로토콜이 사용됩니다 (프레임워크로 표시됨).
이 모드에서는 프레임워크의 HT 컴퓨팅 라이브러리가 IMU 데이터에 대한 모든 사전 처리와 휴대전화 센서에 표시된 휴대전화 움직임과의 조정을 실행합니다.
DYNAMIC_SPATIAL_AUDIO_HARDWARE
: 이 모드는 다음 조건 중 하나가 충족될 때 사용됩니다.
- 지연 시간이 짧은 경우 HID가 ISO 프로토콜을 통해 전달되며 HID를 스페이셜라이저 효과 엔진 (HAL로 표시됨)으로 터널링할 수 있습니다.
- HT가 활성 상태이고 HID 데이터가 스페이셜라이저 효과 엔진으로 터널링될 때 ISO 프로토콜이 사용됩니다 (프레임워크에서 표시됨).
이 모드에서 스페이셜라이저 효과 엔진은 BT 스택 또는 BT 컨트롤러에서 처리되지 않은 IMU 데이터를 직접 수신합니다. 공간 음향 효과 구현은 IMU 데이터에 대한 모든 사전 처리와 휴대전화 센서에 표시된 휴대전화 움직임과의 조정을 실행합니다.
지연 시간 모드 enum은 Spatializer.cpp
의 bluetooth.core.le.dsa_transport_preference
시스템 속성에 매핑됩니다.
스페이셜라이저 지원
오디오 정책 서비스의 스페이셜라이저 컨트롤러는 LE 오디오를 통한 HT 전송 프로토콜 선택을 제어합니다. 스페이셜라이저 효과 엔진 구현은 HeadTracking.ConnectionMode
기능을 사용한 HT 데이터 터널링을 지원함을 나타냅니다.
지원되는 HT 연결 모드는 다음과 같습니다.
FRAMEWORK_PROCESSED
: 오디오 프레임워크는 헤드 투 스테이지 벡터 형식으로 사전 처리된 IMU 데이터를 HAL에 제공합니다. 이 기본 모드는 BT classic의 현재 모드에 해당합니다.
DIRECT_TO_SENSOR_SW
: 스페이셜라이저 효과 엔진은 센서 소프트웨어 스택을 통해 센서에 직접 연결됩니다. 오디오 프레임워크는 센서의 사용 설정 상태만 제어합니다. AOSP libheadtracking
IMU 데이터 사전 처리 또는 DSP 오프로드된 스페이셜라이저 구현을 사용하지 않는 소프트웨어 구현은 DIRECT_TO_SENSOR_SW
모드를 사용할 수 있습니다.
DIRECT_TO_SENSOR_TUNNEL
: 스페이셜라이저 효과 엔진은 하드웨어 터널링을 통해 센서에 직접 연결됩니다. 오디오 프레임워크는 센서의 사용 설정 상태만 제어합니다. DSP 오프로드 스페이셜라이저 구현은 DIRECT_TO_SENSOR_TUNNEL
모드를 사용할 수 있습니다.
지연 시간 모드 선택
프레임워크는 HAL에서 보고하는 지원되는 지연 시간 모드 목록에서 지연 시간 모드를 선택합니다.
지연 시간 모드는 현재 HT 사용 설정 상태, 현재 스페이셜라이저 지원, 전송 메커니즘 간의 우선순위 순서를 설정하는 공급업체 지정 시스템 속성을 기반으로 설정됩니다.
프레임워크는 selectHeadtrackingConnectionMode_l
에서 다음 프로세스를 사용하여 지연 시간 모드를 선택합니다.
- 프레임워크는
bluetooth.core.le.dsa_transport_preference
시스템 속성에서 전송 환경설정을 로드합니다.
- 오디오 HAL에서 보고한 지원되는 지연 시간 모드는 1단계에서 로드된 목록을 기준으로 필터링되고 정렬됩니다.
- 우선순위가 가장 높은 저지연 모드가
iso-hw
이고 스페이셜라이저 구현이 직접 센서 연결을 지원하는 경우 (즉, 스페이셜라이저에 DIRECT_TO_SENSOR_SW
또는 DIRECT_TO_SENSOR_TUNNEL
가 설정됨) 지연 시간 모드는 DYNAMIC_SPATIAL_AUDIO_HARDWARE
로 설정됩니다.
우선순위가 가장 높은 지연 시간 감소 모드가 iso-hw
이고 스페이셜라이저 구현에서 직접 센서 연결을 지원하지 않는 경우 (DIRECT_TO_SENSOR_SW
또는 DIRECT_TO_SENSOR_TUNNEL
가 스페이셜라이저에 설정되지 않음) 다음으로 선호되는 모드 (iso-sw
또는 le-acl
)가 지연 시간 모드 (DYNAMIC_SPATIAL_AUDIO_SOFTWARE
또는 LOW
)를 결정합니다.
다음 기본 모드가 지정되지 않으면 시스템에서 제품 구성 오류를 보고합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Head tracking over LE audio\n\n[Bluetooth (BT) Low Energy (LE) audio](https://www.bluetooth.com/specifications/core54-html/)\nintroduces the Asynchronous Connection-oriented Logical (LE-ACL) and Isochronous\n(LE-ISO) logical transport mechanisms for head tracking (HT) data.\n\nAndroid 15 provides support for latency mode\nadjustments for HT based on whether the LE-ACL or LE-ISO transport mechanism is\nused.\n\nThis page describes how the audio framework, audio HAL, and Bluetooth stack\ninteract to discover and select the LE-ACL or LE-ISO transport mechanisms\nsupported by the host and the headset.\n\nSupport for LE-ACL and LE-ISO\n-----------------------------\n\nAndroid 15 includes support for LE-ACL and LE-ISO\ntransport mechanisms by using a vendor-defined\n[system property](#ht-sys-prop), audio HAL [latency modes](#ht-latency-modes),\nand [spatializer connection modes](#ht-spatial-support).\n\n### System property\n\nThe phone vendor implementation lists the supported transport mechanisms in the\n[`bluetooth.core.le.dsa_transport_preference`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/libsysprop/srcs/android/sysprop/BluetoothProperties.sysprop;l=769) system property. The value is a comma-separated list of strings,\nlisting the [supported transports](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Bluetooth/system/bta/le_audio/le_audio_types.h;l=58) in the order of preference:\n\n- `le-acl`: LE-ACL transport, when the inertial measurement unit (IMU) data is reported through the sensor stack.\n- `iso-hw`: ISO transport with capability to tunnel HT data directly from the Bluetooth controller to the spatializer in the audio DSP.\n- `iso-sw`: ISO transport without tunneling capability, when the IMU data is reported through the sensor stack.\n\n### Latency modes\n\nIn the case of BT LE audio, the mechanism for the BT stack to indicate the\nsupported latency modes to the audio HAL and audio framework is the same as that\ndefined for BT Classic (A2DP). The audio HAL reports the supported latency modes\naccording to the currently selected audio device.\n\nA2DP implementations support only `FREE` and `LOW_LATENCY` modes.\n\nIn contrast, for BT LE audio, the following [latency modes](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/AudioLatencyMode.aidl;l=27)\nare defined in the audio HAL to support the addition of LE-ACL and LE-ISO\ntransport mechanisms:\n\n- `FREE`: This value indicates that there's no specific constraint on the\n latency. This mode is used when low latency isn't supported (indicated by\n the HAL), or when HT isn't active (indicated by the framework).\n\n- `LOW`: This value indicates a relatively low latency (such as, less than\n 100 ms) compatible with HT operation. This mode is used when low\n latency is supported and HID is conveyed over the ACL protocol (indicated by\n the HAL), or when HT is active and no other low latency modes are available\n (indicated by the framework).\n\n- `DYNAMIC_SPATIAL_AUDIO_SOFTWARE`: This mode is used when one of the\n following conditions are met:\n\n - 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).\n - 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).\n\n In this mode, the HT computing library in the framework does all the\n preprocessing on the IMU data and reconciliation with phone movements\n indicated by phone sensors.\n- `DYNAMIC_SPATIAL_AUDIO_HARDWARE`: This mode is used when one of the\n following conditions are met:\n\n - 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).\n - 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).\n\n In this mode, the spatializer effect engine receives the unprocessed IMU\n data directly from the BT stack or BT controller. The spatializer effect\n implementation does all the preprocessing on the IMU data and reconciliation\n with phone movements indicated by phone sensors.\n\nThe latency mode enums are mapped to the [`bluetooth.core.le.dsa_transport_preference`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/libsysprop/srcs/android/sysprop/BluetoothProperties.sysprop;l=769)\nsystem property in [`Spatializer.cpp`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/service/Spatializer.cpp;l=218).\n\n### Spatializer support\n\nThe [spatializer](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/service/Spatializer.cpp)\ncontroller in the audio policy service controls the selection of HT transport\nprotocol over LE audio. The spatializer effect engine implementation indicates\nsupport for HT data tunneling with the [`HeadTracking.ConnectionMode`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/hardware/interfaces/media/aidl/android/media/audio/common/HeadTracking.aidl;l=63) capability.\n\nThe supported HT connection modes are as follows:\n\n- `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.\n- `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.\n- `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.\n\nLatency mode selection\n----------------------\n\nThe framework selects a latency mode from the list of supported\n[latency modes](#ht-latency-modes) that are reported by the HAL.\nThe [latency mode is set](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/service/Spatializer.cpp;l=1056)\nbased on the current HT enable state, current [spatializer support](#ht-spatial-support),\nand the vendor-specified [system property](#ht-sys-prop) that\nestablishes a priority order between transport mechanisms.\n\nThe framework uses the following process in [`selectHeadtrackingConnectionMode_l`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/service/Spatializer.cpp;l=1056)\nto select the latency mode:\n\n1. The framework loads the transport preference from the [`bluetooth.core.le.dsa_transport_preference`](https://cs.android.com/android/platform/superproject/+/android-latest-release:system/libsysprop/srcs/android/sysprop/BluetoothProperties.sysprop;l=769) [system property](#ht-sys-prop).\n2. The supported latency modes reported by the audio HAL are filtered and ordered against the list loaded in step 1.\n3. 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`.\n4. If the highest priority low latency mode is `iso-hw` and the spatializer\n implementation doesn't support direct sensor connection (`DIRECT_TO_SENSOR_SW`\n or `DIRECT_TO_SENSOR_TUNNEL` aren't set in the spatializer), the next preferred\n mode (which is either `iso-sw` or `le-acl`) determines the latency mode (which\n is either `DYNAMIC_SPATIAL_AUDIO_SOFTWARE` or `LOW`).\n\n If the next preferred mode isn't specified, the system reports a product\n configuration error."]]