ماشه صدا

ویژگی Sound Trigger به برنامه‌ها این امکان را می‌دهد که به رویدادهای صوتی خاص مانند کلمات کلیدی به روشی کم مصرف و حساس به حریم خصوصی گوش دهند. موارد استفاده مثال Sound Trigger عبارتند از Assistant و Now Playing.

این صفحه نمای کلی معماری Sound Trigger و رابط HAL (لایه انتزاعی سخت افزار) آن را ارائه می دهد.

پشته ماشه صدا

زیرسیستم Sound Trigger طبق شکل 1 به صورت لایه ای ساخته شده است:

sound_trigger_stack

شکل 1: پشته ماشه صدا

لیست زیر هر لایه نشان داده شده در شکل 1 را با جزئیات بیشتری شرح می دهد:

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

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

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

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

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

رابط HAL ماشه صدا

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

رابط STHAL در زیر /hardware/interfaces/soundtrigger/ مشخص شده است.

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

جریان اصلی تنظیم یک جلسه به صورت زیر در شکل 2 توضیح داده شده است:

sthal_state

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

مراحل زیر هر حالت را با جزئیات بیشتری شرح می دهد:

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

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

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

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

    همین مدل را می توان بعداً دوباره شروع کرد و این روند را می توان هر چند بار که لازم است تکرار کرد.

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

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

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