معماری مجدد SCO مدیریت‌شده صوتی

این صفحه نحوه فعال کردن چارچوب صوتی و «لایه انتزاع سخت‌افزار صوتی» (AHAL) را برای مدیریت اتصال‌های هم‌زمان اتصال‌گرا (SCO) توضیح می‌دهد، فرایندی که به‌عنوان «اتصال SCO مدیریت‌شده صوتی» (AMSCO) شناخته می‌شود.

در Android 17 و بالاتر، چارچوب صدای Android از ویژگی مدیریت SCO برای مدیریت مسیریابی SCO استفاده می‌کند، که در ابتدا توسط چارچوب Bluetooth (BT) انجام می‌شد. این انتقال وضعیت اتصال SCO را از حالتی که تحت مالکیت چارچوب BT است به پیامد پایین‌دستی فعالیت جاری‌سازی صوتی منتقل می‌کند.

با متمرکز کردن مالکیت مسیریابی صوتی در چارچوب صوتی، این ویژگی پیاده‌سازی لایه انتزاع سخت‌افزار صوتی (HAL) را برای SCO با دیگر نمایه‌های BT مثل «نمایه توزیع صوتی پیشرفته» (A2DP) و «صدای LE» هماهنگ می‌کند. این بازسازی تعامل بین مخابرات و پشته‌های BT را ساده‌تر می‌کند و معماری مسیریابی صوتی قوی‌تر و متمرکزتری را امکان‌پذیر می‌کند.

نمای کلی معماری

معماری AMSCO مدیریت اتصال SCO را در چارچوب صوتی Android متمرکز می‌کند، که تصمیمات مسیریابی را براساس فعالیت جاری‌سازی صوتی اتخاذ می‌کند. این معماری با مدل قبلی که در آن پشته BT اتصالات را مدیریت می‌کرد متفاوت است. نقش هر مؤلفه در این معماری به‌شرح زیر است:

‫AHAL جلسه SCO را فقط درصورت برآورده شدن شرایط زیر شروع و تعلیق می‌کند:

  • جاری‌سازی فعالی به دستگاه SCO وصله می‌شود.
  • حالت صدا تنظیم شده است و وصله‌ای برای دستگاه SCO وجود دارد.

وقتی این معیارهای خاص برآورده شود، چارچوب صوتی مانع از داشتن وصله هم‌زمان در دستگاه A2DP می‌شود. چارچوب صوتی دیگر تغییرات وضعیت SCO یا تعلیق‌های A2DP را به AHAL ارسال نمی‌کند.

چارچوب صوتی مدیریت SCO را انجام می‌دهد، بنابراین پشته BT دیگر اتصال یا قطع اتصال صوتی را فراخوانی نمی‌کند. در موارد قطع ارتباط یا خطای پیش‌گیرانه SCO، پشته BT چارچوب صوتی را با AudioManager#onHfpAudioDisconnected مطلع می‌کند.

طرح

از اطلاعات این بخش برای ارزیابی سازگاری زیر و الزامات معماری قبل‌از پیاده‌سازی کردن بازسازی مدیریت SCO استفاده کنید.

سازگاری با نسخه قدیمی

برای اینکه چارچوب بتواند همچنان از دستگاه‌هایی که ممکن است بدون به‌روزرسانی AHAL یا BT AHAL خود به‌روزرسانی سیستم‌عامل دریافت کنند پشتیبانی کند، از دارایی سیستم برای نشان دادن اینکه مدیریت جدید SCO باید فعال شود استفاده کنید. در مواردی که دارایی سیستم غیرفعال باشد یا نسخه HAL قدیمی باشد، مسیر قدیمی تا شش سال حفظ می‌شود.

راه‌اندازی جلسه HFP

AHAL باید از نوع جلسه نمایه دست‌آزاد (HFP) جدید برای شروع یا تعلیق بازپخش استفاده کند، مشابه انواع دیگر جلسه BT. وضعیت جاری‌سازی درنهایت بااستفاده از IBluetoothAudioProviders مختلف مدیریت می‌شود که توسط کلاس Factory بسته به مسیرهای دردسترس شمارش و ساخته می‌شوند.

پشته بلوتوث هر زمان که ممکن باشد از مسیر تخلیه سخت‌افزاری استفاده می‌کند. اولویت کدک‌ها درطول مذاکره به این ترتیب است: سخت‌افزار LC3 بر نرم‌افزار LC3 اولویت دارد، سپس سخت‌افزار mSBC، سپس نرم‌افزار mSBC، و درنهایت سخت‌افزار CVSD بر نرم‌افزار CVSD اولویت دارد.

نمودارهای توالی زیر تعاملات بین AHAL و پشته BT موردنیاز برای ایجاد وضعیت جاری‌سازی را به‌تفصیل شرح می‌دهد.

رویه واگذاری سخت‌افزاری

شکل ۱ نشان می‌دهد که چگونه AHAL و پشته BT برای ایجاد مسیر داده سخت‌افزاری مستقیم برای صدای SCO هماهنگ می‌شوند:

hw-offload-procedure

شکل ۱. رویه واگذاری سخت‌افزار.

رویه مسیر داده‌های نرم‌افزار

شکل ۲ فرایند مدیریت داده‌های صوتی را که به پردازش نرم‌افزار سیستم نیاز دارند نشان می‌دهد:

sw-data-path

شکل ۲. رویه مسیر داده‌های نرم‌افزار.

روش مذاکره مجدد کدک

وقتی درگاه صوتی (AG) فرمان کدک دردسترس جدید BT (AT+BAC) را دریافت می‌کند، AG روند مذاکره کدک را بازراه‌اندازی می‌کند. شکل ۳ رویه مذاکره مجدد کدک را نشان می‌دهد:

codec-renego-process

شکل ۳. روش مذاکره مجدد کدک.

تأثیر بر HeadsetStateMachine

ماشین حالت هدست لایه جاوا (که با کلاس HeadsetStateMachine نشان داده می‌شود) تا حد زیادی بدون تغییر باقی می‌ماند، به‌جز حالت AUDIO_CONNECTED که توسط رویدادهای پشته بومی هدایت می‌شود. در لایه Java، سیستم دیگر connectAudioNative یا disconnectAudioNative را آغاز نمی‌کند. درعوض، سیستم به تغییرات وضعیت اتصال صوتی از پشته بومی پاسخ می‌دهد. این تغییرات توسط دستورات AHAL در IBluetoothAudioProvider یا IBluetoothAudioPort فعال می‌شوند.

پیاده‌سازی

برای ادغام بازسازی کد مدیریت SCO، ارتباط بین پشته بلوتوث و چارچوب صوتی را به‌روز کنید.

برای پیاده‌سازی این ویژگی، این مراحل را دنبال کنید:

  1. چارچوب صوتی را از تغییرات بلوتوث فعال مطلع می‌کند تا به مدیریت صحیح شروع و پایان SCO درطول اتصالات دستگاه HFP و مدیریت تغییرات دستگاه فعال کمک کند. از AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo) برای ارائه این اطلاعات به چارچوب صوتی استفاده کنید.

    conn-hfp

    شکل ۴. دستگاه HFP را متصل کنید.

    چارچوب صوتی به‌جای استفاده از همه‌فرستی‌های قدیمی، از AudioManagerAudioDeviceCallback#onAudioDevicesAdded بازخوان برای نشان دادن وضعیت دستگاه صوتی استفاده می‌کند.

  2. کنترل جاری‌سازی AHAL را بااستفاده از setCommunicationDevice(AudioDeviceInfodevice) به‌عنوان نقطه کنترل اصلی برای شروع اتصال SCO پیاده‌سازی کنید.

    اگر HfpTransport::StartRequest BluetoothAudioCtrlAck::PENDING را برگرداند، AHAL باید درخواست را دوباره امتحان کند زیرا ماشین حالت HFP ایجاد نشده است.

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

بخش‌های زیر سفرهای کاربر حیاتی (CUJ) معمول را شرح می‌دهند.

جریان تماس مخابرات

بازسازی مدیریت SCO،‏ phoneStateChanged را به تابعی مسدودکننده تغییر می‌دهد. این اصلاح باعث می‌شود که telecom منتظر بماند تا phoneStateChanged اجرا در BluetoothInCallService.onCallAdded روش تکمیل شود و سپس telecom میانای برنامه‌سازی کاربردی چارچوب صوتی را برای شروع ایجاد SCO فراخوانی کند.

تماس-مخابرات

شکل ۵. تماسی را ازطریق شرکت مخابراتی پاسخ دهید یا شروع کنید.

جریان تماس VOIP

چارچوب صوتی با فراخوانی روش BluetoothHeadset.startScoUsingVirtualVoiceCall فرایند را شروع می‌کند. پس‌از اینکه پشته BT نتیجه‌ای را به چارچوب صوتی ارائه می‌دهد، چارچوب به AHAL دستور می‌دهد startStream را اجرا کند. شکل زیر این جریان را نشان می‌دهد:

تماس-ویپ

شکل ۶. تماسی را ازطریق VOIP پاسخ دهید یا شروع کنید.

تشخیص صدا

برای تشخیص گفتار دست‌آزاد (HF) و تشخیص گفتار آغازشده توسط AG، پشته BT باید از چارچوب صوتی درخواست کند که SCO را بااستفاده از AudioManager.setCommunicationDevice باز کند. این موضوع در شکل زیر نشان داده شده است:

تشخیص صدا

شکل ۷. راه‌اندازی SCO تشخیص صدا.

اتصال صوتی

پشته بلوتوث با درخواست چارچوب صوتی با AudioManager.setCommunicationDevice(AudioDeviceInfo) درطول تشخیص صدا، اتصال SCO را آغاز می‌کند. اگر تماسی فعال باشد، پشته BT به‌جای آن BluetoothInCallService#requestBluetoothAudio را از پشته مخابرات درخواست می‌کند.

این فرایند در شکل زیر نشان داده شده است:

اتصال صوتی

شکل ۸. اتصال صوتی.

اعتبارسنجی و آزمایش

برای تأیید اینکه این ویژگی به‌درستی ادغام شده است و استانداردهای کیفیت را برآورده می‌کند، سازندگان دستگاه باید آزمایش‌های زیر را اجرا کنند:

  • CTS Verifier: از CTS Verifier برای آزمایش تعاملی مسیریابی صدا درطول تماس‌ها استفاده کنید.
  • مجموعه آزمایش ارائه‌دهنده (VTS): تعاملات AHAL و BT AHAL را بااستفاده از VTS اعتبارسنجی کنید.

الزامات

این ویژگی مشمول الزامات زیر است:

  • AHAL: پیاده‌سازی به AHAL سازگاری نیاز دارد که از مسیر مدیریت SCO بازسازی‌شده پشتیبانی کند.