راه‌انداز صدا

ویژگی «محرک صدا» به برنامه‌ها امکان می‌دهد به روشی کم‌مصرف و حساس به حریم خصوصی به رویدادهای صوتی خاصی، مثل کلمات کلیدی، گوش دهند. «دستیار» و «درحال پخش» نمونه‌هایی از موارد استفاده «محرک صدا» هستند.

این صفحه نمای کلی از معماری «محرک صدا» و میانای HAL (لایه انتزاع سخت‌افزار) آن ارائه می‌دهد.

پشته «محرک صدا»

زیرسیستم «راه‌انداز صدا» به‌صورت لایه‌ای ساخته شده است، همان‌طور که در «شکل ۱» نشان داده شده است:

sound_trigger_stack

شکل ۱: پشته «راه‌انداز صدا»

فهرست زیر هر لایه نشان‌داده‌شده در «شکل ۱» را با جزئیات بیشتر شرح می‌دهد:

  • لایه HAL (به رنگ سبز) حاوی کد مختص فروشنده است که میانای لایه انتزاع سخت‌افزار محرک صدا (STHAL) را پیاده‌سازی می‌کند.

  • SoundTriggerMiddleware (به‌رنگ زرد) بالای میانای HAL قرار دارد. این سرویس با HAL ارتباط برقرار می‌کند و مسئولیت عملکردهایی مثل هم‌رسانی HAL بین مشتریان مختلف، گزارش‌گیری، اجرای مجوزها، و مدیریت سازگاری با نسخه‌های قدیمی‌تر HAL را برعهده دارد.

  • سیستم SoundTriggerService (به رنگ آبی) بالای میان‌افزار قرار دارد. این ویژگی یکپارچه‌سازی با ویژگی‌های دیگر سیستم، مثل تلفن و رویدادهای باتری را تسهیل می‌کند. همچنین پایگاه داده‌ای از مدل‌های صدا را نگهداری می‌کند که با شناسه‌های یکتا نمایه‌سازی شده‌اند.

  • بالای لایه SoundTriggerService، پشته (به رنگ قهوه‌ای) ویژگی‌های خاص «دستیار» و برنامه‌های عمومی را به‌طور جداگانه مدیریت می‌کند.

عملکرد پشته «راه‌انداز صدا» ارائه رویدادهای مجزایی است که نشان‌دهنده رویدادهای صوتی و راه‌انداز هستند. در اکثر موارد، پشته «محرک صدا» با صدا سروکار ندارد. پس‌از دریافت رویدادهای راه‌انداز، برنامه‌ها با باز کردن شیء AudioRecord ازطریق چارچوب «صدا»، به جاری‌سازی صوتی واقعی در زمان رویدادها دسترسی پیدا می‌کنند. میاناهای برنامه‌سازی کاربردی لایه انتزاع سخت‌افزار محرک صدا دستگیره‌ای با رویداد راه‌اندازی‌شده ارائه می‌دهند که با چارچوب صوتی استفاده می‌شود. بنابراین، ازآنجایی‌که Sound Trigger HAL و Audio HAL در پشت صحنه به هم متصل هستند، معمولاً از یک فرایند مشترک استفاده می‌کنند.

میانای لایه انتزاع سخت‌افزار محرک صدا

میانای «لایه انتزاع سخت‌افزار محرک صدا» (STHAL) بخش مختص فروشنده پشته «محرک صدا» است و تشخیص سخت‌افزاری کلمات کلیدی و صداهای دیگر را مدیریت می‌کند. STHAL یک یا چند موتور ارائه می‌دهد که هرکدام الگوریتم متفاوتی را اجرا می‌کنند که برای شناسایی کلاس خاصی از صداها طراحی شده است. وقتی STHAL راه‌اندازی را تشخیص می‌دهد، رویدادی به چارچوب ارسال می‌کند و سپس تشخیص را متوقف می‌کند.

میانای STHAL تحت /hardware/interfaces/soundtrigger/ مشخص شده است.

میانای ISoundTriggerHw از توانایی داشتن یک یا چند جلسه تشخیص درحال اجرا در زمان مشخص و گوش دادن به رویدادهای صوتی پشتیبانی می‌کند. تماس با ISoundTriggerHw.getProperties() ساختار Properties را برمی‌گرداند که حاوی شرح و قابلیت‌های پیاده‌سازی است.

جریان اصلی راه‌اندازی جلسه در «شکل ۲» به‌صورت زیر توضیح داده شده است:

sthal_state

شکل ۲: نمودار وضعیت STHAL

مراحل زیر هر وضعیت را با جزئیات بیشتری توضیح می‌دهد:

  1. کارخواه HAL مدلی را بااستفاده از loadSoundModel() یا loadPhraseSoundModel() بار می‌کند. شیء مدل ارائه‌شده نشان می‌دهد که از کدام الگوریتم (موتور) تشخیص مختص پیاده‌سازی استفاده شود، و همچنین پارامترهای قابل‌اعمال برای این الگوریتم را مشخص می‌کند. درصورت موفقیت، این روش‌ها یک دستگیره برمی‌گردانند که برای ارجاع به این مدل در تماس‌های بعدی استفاده می‌شود.

  2. پس‌از اینکه مدل باموفقیت بار شد، مشتری HAL برای شروع تشخیص startRecognition() را فرا می‌خواند. تا زمانی که یکی از رویدادهای زیر رخ دهد، تشخیص در پس‌زمینه ادامه می‌یابد:

    1. stopRecognition() در این مدل فراخوانی شده است.
    2. موردی شناسایی شد.
    3. به‌دلیل محدودیت‌های منابع، برای مثال، زمانی که مورد استفاده با اولویت بالاتر شروع شده باشد، تشخیص متوقف می‌شود.

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

    همان مدل را می‌توان در زمان دیگری دوباره شروع کرد و این فرایند را می‌توان هر چند بار که لازم باشد تکرار کرد.

  3. درنهایت، مدل غیرفعالی که دیگر موردنیاز نیست ازطریق unloadModel() توسط مشتری HAL بارگیری می‌شود.

مدیریت خطاهای HAL

برای اطمینان از عملکرد قابل‌اعتماد و یکپارچه بین پیاده‌سازی‌های درایور، در Android 11، هر کد خطای غیرموفقی که از لایه انتزاع سخت‌افزار برگردانده می‌شود به‌عنوان خطای برنامه‌نویسی درنظر گرفته می‌شود که برای بازیابی از آن باید فرایند لایه انتزاع سخت‌افزار را بازراه‌اندازی کرد. این یک استراتژی بازیابی آخرین راه‌حل است و انتظار این است که چنین مواردی در یک سیستم درست کارکرد رخ ندهد.