از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
ردیابی سر از طریق صدای LE
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
صدای بلوتوث (BT) کم انرژی (LE) مکانیسم های انتقال منطقی منطقی اتصال گرا ناهمزمان (LE-ACL) و هم زمان (LE-ISO) را برای داده های ردیابی سر (HT) معرفی می کند.
اندروید 15 از تنظیمات حالت تأخیر برای HT بر اساس استفاده از مکانیسم انتقال LE-ACL یا LE-ISO پشتیبانی میکند.
این صفحه نحوه تعامل چارچوب صوتی، HAL صوتی و پشته بلوتوث را برای کشف و انتخاب مکانیسمهای انتقال LE-ACL یا LE-ISO که توسط میزبان و هدست پشتیبانی میشوند، توضیح میدهد.
پشتیبانی از LE-ACL و LE-ISO
Android 15 شامل پشتیبانی از مکانیسمهای انتقال LE-ACL و LE-ISO با استفاده از ویژگی سیستم تعریفشده توسط فروشنده، حالتهای تأخیر صوتی HAL و حالتهای اتصال فضاساز است .
ویژگی سیستم
پیاده سازی فروشنده تلفن مکانیسم های حمل و نقل پشتیبانی شده را در ویژگی سیستم bluetooth.core.le.dsa_transport_preference
فهرست می کند. مقدار، لیستی از رشتهها است که با کاما از هم جدا شدهاند، که انتقالهای پشتیبانیشده را به ترتیب اولویت فهرست میکند:
-
le-acl
: انتقال LE-ACL، زمانی که داده های واحد اندازه گیری اینرسی (IMU) از طریق پشته سنسور گزارش می شود. -
iso-hw
: انتقال ISO با قابلیت تونل کردن داده های HT به طور مستقیم از کنترلر بلوتوث به فضاساز در DSP صوتی. -
iso-sw
: انتقال ISO بدون قابلیت تونل زنی، زمانی که داده های IMU از طریق پشته سنسور گزارش می شود.
حالت های تاخیر
در مورد صدای BT LE، مکانیسم پشته BT برای نشان دادن حالتهای تأخیر پشتیبانی شده به HAL صوتی و چارچوب صوتی، همان چیزی است که برای BT Classic (A2DP) تعریف شده است. HAL صوتی حالت های تأخیر پشتیبانی شده را مطابق با دستگاه صوتی انتخاب شده فعلی گزارش می کند.
پیاده سازی های A2DP فقط از حالت های FREE
و LOW_LATENCY
پشتیبانی می کنند.
در مقابل، برای صدای BT LE، حالتهای تأخیر زیر در HAL صوتی برای پشتیبانی از اضافه شدن مکانیسمهای انتقال LE-ACL و LE-ISO تعریف شدهاند:
FREE
: این مقدار نشان می دهد که محدودیت خاصی در تأخیر وجود ندارد. این حالت زمانی استفاده میشود که تأخیر کم پشتیبانی نمیشود (که با HAL نشان داده میشود)، یا زمانی که HT فعال نیست (با چارچوب نشان داده میشود).
LOW
: این مقدار یک تأخیر نسبتاً کم (مانند کمتر از 100 میلی ثانیه) را نشان می دهد که با عملکرد HT سازگار است. این حالت زمانی استفاده میشود که از تأخیر کم پشتیبانی میشود و HID از طریق پروتکل ACL (که با HAL نشان داده میشود)، یا زمانی که HT فعال است و هیچ حالت تأخیر کم دیگری در دسترس نیست (که توسط چارچوب نشان داده شده است) استفاده میشود.
DYNAMIC_SPATIAL_AUDIO_SOFTWARE
: این حالت زمانی استفاده می شود که یکی از شرایط زیر برآورده شود:
- وقتی تأخیر کم پشتیبانی میشود، HID از طریق پروتکل ISO منتقل میشود و HID را نمیتوان به موتور اثر فضاساز (که با HAL نشان داده میشود) تونل کرد.
- هنگامی که HT فعال است و پروتکل ISO زمانی استفاده می شود که فریم ورک صوتی داده های HID را به موتور افکت فضاساز (که توسط فریم ورک نشان داده شده است) ارائه می دهد.
در این حالت، کتابخانه محاسباتی HT در چارچوب، تمام پیش پردازش ها را روی داده های IMU و تطبیق با حرکات تلفن نشان داده شده توسط حسگرهای تلفن انجام می دهد.
DYNAMIC_SPATIAL_AUDIO_HARDWARE
: این حالت زمانی استفاده می شود که یکی از شرایط زیر برآورده شود:
- هنگامی که تأخیر کم پشتیبانی می شود، HID از طریق پروتکل ISO منتقل می شود و HID را می توان به موتور اثر فضاساز (که با HAL نشان داده شده است) تونل کرد.
- هنگامی که HT فعال و پروتکل ISO زمانی که داده های HID به موتور اثر فضای ساز تونل می شوند (که توسط چارچوب نشان داده شده است) استفاده می شود.
در این حالت، موتور افکت فضای ساز داده های پردازش نشده IMU را مستقیماً از پشته BT یا کنترلر BT دریافت می کند. اجرای افکت فضایی ساز تمام پیش پردازش ها را روی داده های IMU و تطبیق با حرکات تلفن نشان داده شده توسط حسگرهای تلفن انجام می دهد.
شمارههای حالت تأخیر به ویژگی سیستم bluetooth.core.le.dsa_transport_preference
در Spatializer.cpp
نگاشت میشوند.
پشتیبانی فضایی ساز
کنترل کننده فضایی ساز در سرویس خط مشی صدا، انتخاب پروتکل حمل و نقل HT را بر روی صدای LE کنترل می کند. پیاده سازی موتور افکت فضای ساز نشان دهنده پشتیبانی از تونل زنی داده HT با قابلیت HeadTracking.ConnectionMode
است.
حالت های اتصال HT پشتیبانی شده به شرح زیر است:
-
FRAMEWORK_PROCESSED
: چارچوب صوتی داده های IMU از پیش پردازش شده را در قالب برداری سر به مرحله در HAL ارائه می دهد. این حالت پیش فرض مربوط به حالت فعلی با کلاسیک BT است. -
DIRECT_TO_SENSOR_SW
: موتور جلوه فضایی ساز مستقیماً از طریق پشته نرم افزار حسگر به سنسور متصل می شود. چارچوب صوتی فقط وضعیت فعال سنسور را کنترل می کند. پیادهسازیهای نرمافزاری که از پیشپردازش دادههای IMU libheadtracking
AOSP یا پیادهسازی فضایساز بارگذاریشده 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 و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]