بلوتوث صدای کم انرژی

بلوتوث کم‌مصرف صوتی (LEA) تضمین می‌کند که کاربران می‌توانند بدون کاهش عمر باتری، صدای باکیفیتی دریافت کنند و به آنها اجازه می‌دهد تا به راحتی بین موارد استفاده مختلف جابجا شوند. اندروید ۱۳ (سطح API ۳۳) شامل پشتیبانی داخلی از LEA است.

بیشتر هدست‌های LEA تا زمانی که سهم بازار دستگاه‌های منبع LEA افزایش یابد، دو حالته خواهند بود. کاربران باید بتوانند هر دو انتقال را روی هدست‌های دو حالته خود جفت و تنظیم کنند.

موارد استفاده

شما می‌توانید LEA را برای موارد استفاده زیر ادغام کنید:

  • اشتراک‌گذاری صدا: کاربران می‌توانند همزمان چندین جریان صوتی را با یک یا چند دستگاه پخش صدا به اشتراک بگذارند. صدا بین دستگاه منبع و دستگاه‌های متصل همگام‌سازی می‌شود.

  • پخش صدا: کاربران می‌توانند صدا را برای دوستان و خانواده پخش کنند، ضمن اینکه برای کسب اطلاعات، سرگرمی یا دسترسی به پخش‌های عمومی نیز متصل می‌شوند.

  • پشتیبانی از کدک صوتی LC3: این کدک صوتی پیش‌فرض است و جایگزین کدک SBC مورد استفاده برای A2DP (رسانه) و mSBC در HFP (صدا) می‌شود. LC3 کارآمدتر، قابل پیکربندی مجدد و با کیفیت بالاتر است.

  • بهبود نمونه‌برداری صدا: هدست‌ها می‌توانند هنگام استفاده از میکروفون، کیفیت صدای خروجی بالایی را حفظ کنند. بلوتوث کلاسیک هنگام استفاده از میکروفون‌های بلوتوث، کیفیت صدا را کاهش می‌دهد. با BLE Audio، نمونه‌برداری ورودی و خروجی می‌تواند به ۳۲ کیلوهرتز برسد.

  • میکروفون استریو: دستگاه‌های شنیداری می‌توانند صدا را با میکروفون‌های استریو ضبط کنند تا صدای فضایی را بهبود بخشند.

  • پشتیبانی از پروفایل سمعک (HAP): HAP در مقایسه با پروتکل‌های قبلی ASHA، دسترسی و استفاده‌ی بیشتری را در اختیار کاربران قرار می‌دهد. کاربران می‌توانند از سمعک‌های خود برای تماس‌های تلفنی و برنامه‌های VoIP استفاده کنند.

  • پشتیبانی از پروتکل ویژگی پیشرفته (EATT): EATT به توسعه‌دهندگان اجازه می‌دهد تا چندین دستور را به‌طور همزمان به دستگاه‌های شنیداری جفت‌شده ارسال کنند.

سناریوهای کلیدی

چهار دسته اصلی از موارد استفاده وجود دارد:

  1. مکالمه‌ای: برنامه‌های شماره‌گیر و VoIP که به مسیریابی ارتباطی با تأخیر کم نیاز دارند، صدای با کیفیت بالا و مصرف باتری کمتری ارائه می‌دهند.

  2. بازی: میکروفون همزمان و پخش با کیفیت بالا به بازی‌ها اجازه می‌دهد تا صدای با کیفیت بالا را به دستگاه‌های شنیداری منتقل کنند. یک برنامه بازی می‌تواند زمانی که میکروفون بلوتوث را آماده استفاده می‌کند، به ورودی صدای BLE دسترسی پیدا کند. سپس، هنگامی که یک بازیکن مکالمه زنده را با یک بازیکن دیگر آغاز می‌کند، برنامه بازی می‌تواند بدون تأخیر از داده‌های میکروفون استفاده کند.

  3. رسانه: برنامه‌های رسانه‌ای مجاز به تنظیم دستگاه مورد نظر مدیر صدا هستند. کاربر می‌تواند با تغییر دستگاه مورد نظر خود از داخل تنظیمات سیستم، این مورد را لغو کند.

  4. دسترسی‌پذیری: سمعک‌هایی که از BLE Audio پشتیبانی می‌کنند، اکنون می‌توانند از میکروفون استفاده کنند و به کاربران این امکان را می‌دهند که به طور مداوم از سمعک خود برای تماس استفاده کنند.

APIها و متدهای صوتی BLE

APIها و روش‌های زیر برای پشتیبانی از دستگاه‌های شنیداری BLE Audio مورد نیاز هستند:

مدیر صدا

  • setCommunicationDevice() دستگاه صوتی مورد استفاده برای موارد ارتباطی، مانند تماس‌های صوتی یا تصویری، را انتخاب می‌کند. برنامه‌های چت صوتی یا تصویری می‌توانند از این متد برای انتخاب دستگاه صوتی متفاوتی غیر از دستگاهی که به طور پیش‌فرض توسط پلتفرم انتخاب شده است، استفاده کنند. این API جایگزین APIهای منسوخ شده زیر می‌شود: startBluetoothSco() ، stopBluetoothSco() و setSpeakerphoneOn() .
  • clearCommunicationDevice() پس از اتمام یک فراخوانی یا جلسه در برنامه شما فراخوانی می‌شود تا اطمینان حاصل شود که کاربر هنگام جابجایی بین برنامه‌های مختلف، تجربه خوبی دارد.

پروفایل بلوتوث

  • BluetoothLeAudio سرویس بلوتوث را از طریق شیء پروکسی کنترل می‌کند.

خدمات تماس تلفنی مخابراتی

  • InCallService#requestCallEndpointChange() جایگزین APIهای منسوخ‌شده‌ی InCallService.setAudioRoute() و InCallService.requestBluetoothAudio() می‌شود تا به برنامه‌ها اجازه دهد مسیریابی صوتی را به یک CallEndpoint خاص درخواست کنند. کلاینت‌ها نباید هنگام درخواست تغییر، CallEndpoint خود را تعریف کنند. در عوض، نقطه پایانی جدید باید یکی از نقاط پایانی معتبر ارائه شده توسط InCallService.onAvailableCallEndpointsChanged(java.util.List) باشد.
  • CallEndpoint.TYPE_BLUETOOTH جریان صوتی را از طریق بلوتوث هدایت می‌کند.
  • این APIهای InCallService که قبلاً ذکر شدند، طوری طراحی شده‌اند که توسط برنامه تلفن پیش‌فرض روی تلفن اندروید یا سایر سطوح تماس مانند پوشیدنی‌ها، خودروها یا سایر دستگاه‌های بلوتوثی که ممکن است بخواهند روی مسیریابی صوتی تأثیر بگذارند، مورد استفاده قرار گیرند.

کنترل تماس‌های مخابراتی

اطلاعات دستگاه صوتی

  • AudioDeviceInfo.TYPE_BLE_HEADSET نوع دستگاه صوتی را به عنوان یک دستگاه LEA توصیف می‌کند. برای شناسایی اینکه آیا دستگاه قابل شنیدن یک دستگاه LEA است یا خیر، استفاده می‌شود.

ضبط کننده صدا

  • setPreferredDevice() دستگاه مورد نظر برای مسیریابی صوتی را تنظیم می‌کند. کاربر می‌تواند این مورد را در تنظیمات سیستم لغو کند.

آداپتور بلوتوث

  • isLeAudioSupported() : یک ثابت @BluetoothStatusCodes ( FEATURE_SUPPORTED ، FEATURE_NOT_SUPPORTED یا یک کد خطا) را برمی‌گرداند که نشان می‌دهد آیا سخت‌افزار دستگاه از LE Audio پشتیبانی می‌کند یا خیر.
  • isLeAudioBroadcastSourceSupported() : یک ثابت @BluetoothStatusCodes ( FEATURE_SUPPORTED ، FEATURE_NOT_SUPPORTED یا یک کد خطا) را برمی‌گرداند که نشان می‌دهد آیا سخت‌افزار دستگاه از منبع پخش LE Audio پشتیبانی می‌کند یا خیر.

راهنماهای مبتنی بر مورد استفاده

در زیر دستورالعمل‌هایی برای پیاده‌سازی LEA بر اساس موارد استفاده خاص ارائه شده است.

کاربردهای ارتباط صوتی

برنامه‌های ارتباط صوتی می‌توانند مسیریابی صوتی و وضعیت دستگاه را با مدیریت خودکار وضعیت خود یا با استفاده از Telecom API که مسیریابی صوتی و منطق وضعیت را برای شما انجام می‌دهد، مدیریت کنند.

این دو راهکار به شما امکان می‌دهند به سرعت و به راحتی مسیریابی صوتی را کنترل کرده و بین دستگاه‌های بلوتوث جابجا شوید. برای اطلاعات بیشتر، به راهنمای تماس‌های مدیریت‌شده‌ی مخابرات مراجعه کنید.

کاربردهای ضبط صدا

  • ضبط‌کننده رسانه: هنگام ضبط صدا با استفاده از ضبط‌کننده رسانه، اگر دستگاه بلوتوثی شما از LEA پشتیبانی کند، اکنون می‌توانید به صورت استریو ضبط کنید. راهنمای ضبط صدا را بررسی کنید.

توصیه های هدست LE Audio (LEA).

با انتشار هدست‌های بیشتر LEA، ما در آزمایش‌های دنیای واقعی مشکلاتی را کشف کرده‌ایم که تجربه کاربری را کاهش می‌دهد. این مشخصات همه این مشکلات را پوشش نمی‌دهد. جدول زیر لیستی از توصیه‌هایی را ارائه می‌دهد که تولیدکنندگان هدست LEA باید برای بهبود تجربه کاربری برای کاربران اندروید دنبال کنند.

توضیحات زمینه
پشتیبانی از استخراج کلید انتقال متقابل (CTKD) برای هدست‌های دو حالته:
  • پشتیبانی از استخراج کلید برای جفت‌سازی کلاسیک به LE و جفت‌سازی LE به کلاسیک.
 بیشتر هدست‌های جدید LEA تا زمانی که سهم بازار دستگاه منبع LEA افزایش یابد، دو حالته خواهند بود. مهم است که کاربران بتوانند هدست‌های دو حالته خود را به طور یکپارچه جفت کنند و هر دو انتقال را تنظیم کنند. این موضوع برای Google Fast Pair نیز مهم است.

اگر می‌خواهید هدست‌های LEA شما به طور قابل اعتمادی دوباره به دستگاه‌های منبع متصل شوند، از اعلان‌های هدفمند (TA) پشتیبانی کنید.

هدفون‌های صوتی LE باید از TAها برای درخواست اتصال ورودی از دستگاه‌های مرکزی استفاده کنند.

به BT SIG آینده اضافه خواهد شد.

 برخلاف مدل پیجینگ BR/EDR که در آن اتصال می‌تواند توسط تلفن یا هدست آغاز شود، اتصال در LEA باید توسط دستگاه مرکزی آغاز شود. در حال حاضر، بسیاری از هدست‌ها از TAها استفاده نمی‌کنند، به این معنی که دستگاه مرکزی ممکن است نتواند بدون اضافه کردن دستگاه جانبی به لیست مجاز، دوباره به آن متصل شود. با این حال، یک راه حل لیست مجاز ممکن است مانع از اتصال هدست به یک دستگاه مرکزی دیگر شود. بنابراین، مهم است که هدست‌های LEA به درستی از TAها پشتیبانی کنند تا دستگاه مرکزی بتواند بدون راه حل‌هایی که ممکن است اتصالات چند نقطه‌ای را قطع کنند، به طور قابل اعتمادی دوباره متصل شود.
قابلیت کشف بهینه برای هدفون‌های دو حالته
  • هدفون اصلی - قطعه BR/EDR باید با استفاده از آدرس عمومی خود تبلیغ کند و امکان استعلام و اسکن صفحه را با نام خود از طریق EIR فراهم کند و بیت صوتی LE را در کلاس‌های اصلی سرویس کلاس دستگاه (CoD) روی ۱۴ روی ۱ تنظیم کند.
  • هدفون اصلی - جزء LE : هدفون اصلی باید یک تبلیغ قابل اتصال و قابل کشف (محدود یا عمومی) را با استفاده از همان آدرس عمومی به عنوان جزء BR/EDR و همان نام محلی کامل به عنوان جزء BR/EDR اجرا کند، و دسته بندی ظاهری آن به عنوان یک دسته بندی ظاهری مناسب که با نوع دستگاه از راه دور مطابقت دارد، تنظیم شود، با این انتظار که دستگاه مرکزی از این اطلاعات برای تنظیم رابط کاربری و سیاست‌های مسیریابی صوتی خود استفاده کند.
  • هدفون ثانویه - فقط LE : هدفون ثانویه باید یک تبلیغ قابل اتصال، غیرقابل کشف را با دسته‌بندی ظاهری مناسب که با نوع دستگاه از راه دور مطابقت دارد، اجرا کند، با این انتظار که دستگاه مرکزی از این اطلاعات برای تنظیم رابط کاربری و سیاست‌های مسیریابی صوتی خود استفاده کند.

    ایربادها باید به صورت پویا یک رهبر از گروه CSIP را به عنوان دستگاه اصلی انتخاب کنند. اگر ایرباد حالت دوگانه دارد، دستگاه اصلی نیز باید حالت دوگانه داشته باشد تا اطمینان حاصل شود که هر دو عملکرد LE و Classic پس از جفت شدن به درستی کار می‌کنند.

 این امر مانع از نمایش ورودی‌های تکراری برای ایربادهای دو حالته LEA در تنظیمات بلوتوث می‌شود، که ممکن است کاربران را گیج کرده و تجربه جفت‌سازی LEA را به خطر بیندازد.

انتخاب رهبر پویا به ویژه برای دستگاه‌های دو حالته که به صورت تدریجی جفت می‌شوند، اهمیت دارد. به عنوان مثال، اگر در جفت‌سازی اولیه فقط یک ایرباد موجود باشد، باید خود را به عنوان یک دستگاه دو حالته نشان دهد. وقتی کاربری بعداً ایرباد دوم را جفت می‌کند، فقط باید با مؤلفه LE جفت شود و CSIP مطمئن می‌شود که آنها در اندروید با هم گروه‌بندی شده‌اند.

آدرس شناسایی در طول جفت‌سازی توصیه می‌شود زیرا مؤلفه BR/EDR از قبل آدرس عمومی دستگاه را در معرض دستگاه‌های مجاور قرار می‌دهد.

پشتیبانی از پروتکل ویژگی بهبود یافته (EATT) . جفت شدن و تأخیر اتصال را کاهش می‌دهد.
پشتیبانی از ذخیره‌سازی قوی GATT. تأخیر اتصال را کاهش می‌دهد، مخصوصاً برای هدفون‌های TWS.
پشتیبانی از زیرسازی اتصال . امکان زمان‌بندی بسته‌های انعطاف‌پذیرتر و صرفه‌جویی بالقوه در مصرف باتری را فراهم می‌کند.
اطمینان حاصل کنید که در طول پیش‌پردازش و پس‌پردازش، چه برای پخش و چه برای ضبط، خط لوله پردازش سیگنال می‌تواند با فرکانس‌های ۱۶، ۲۴، ۳۲ و ۴۸ کیلوهرتز کار کند و همچنین از فرکانس‌های بالاتر پشتیبانی کند . از نرخ نمونه‌برداری بالاتر پشتیبانی‌شده برای مسیرهای ضبط تماس LEA یا VoIP و پخش رسانه بهره می‌برد.
پشتیبانی از کنترل توان LE مدیریت بهتر مصرف برق

پشتیبانی از نوع متن

توضیحات زمینه
از تمام انواع متن مشخص شده در شماره‌های اختصاص داده شده ۶.۱۲.۳ استفاده کنید، مگر اینکه هدست صراحتاً از نوع متن مشخص شده پشتیبانی نکند. برای مثال، اگر نوع زمینه "بازی" پشتیبانی نشود، اندروید صداهای بازی را ارسال خواهد کرد. به طور خاص، توجه داشته باشید که نوع زمینه "نامشخص" به معنای "هر نوع زمینه‌ای" نیست و انواع زمینه پشتیبانی نشده را پوشش نمی‌دهد.

وقتی دستگاه مرکزی با ASCS دستگاه جانبی تعامل دارد، دستگاه جانبی باید به MCS و TBS دستگاه مرکزی متصل شود.

دستگاه مرکزی ممکن است همیشه از صدای LE به عنوان مسیر پخش استفاده نکند زیرا ممکن است به استفاده از A2DP یا HFP بازگردد. دستگاه جانبی می‌تواند از تعامل ASCS به عنوان نشانه‌ای از اینکه آیا دستگاه مرکزی از صدای LE برای پخش استفاده خواهد کرد یا خیر، استفاده کند.

چند نمونه از تعاملات ASCS عبارتند از خواندن، نوشتن و ثبت اعلان.