ماشه صدا

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

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

پشته محرک صدا

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

شکل ۱: مجموعه تریگر صدا

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

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

  نکته: پیاده‌سازی مستقیم رابط STHAL به جای تبدیل شدن به یک رابط در کنار پیاده‌سازی یک HAL قدیمی توصیه می‌شود.

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

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

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

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

توجه: از آنجایی که مدل‌ها و انواع داده‌ها برای چارچوب زیرسیستم Sound Trigger مبهم هستند، انتظار می‌رود که برنامه‌ها و پیاده‌سازی HAL یک «قرارداد پنهان» را حفظ کنند، یعنی محتوای واقعی، قالب و معنای آن انواع داده‌ها مورد توافق قرار گیرد. از این رو، برنامه‌هایی که از Sound Trigger استفاده می‌کنند، به جای اینکه توسط توسعه‌دهندگان مستقل ارائه شوند، توسط فروشنده ارائه می‌شوند.

رابط کاربری HAL تریگر صدا

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

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

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

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

شکل ۲: نمودار حالت STHAL

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

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

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

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

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

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

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

توجه: هنگامی که یک مدل شروع می‌شود، کلاینت HAL می‌تواند تابع forceRecognitionEvent() را برای ایجاد یک رویداد تشخیص اجباری فراخوانی کند. رویداد برگشتی مشابه یک رویداد تشخیص عادی است، اما فیلد وضعیت آن روی FORCED تنظیم شده است. چنین رویدادهای تشخیصی به طور خودکار تشخیص را متوقف نمی‌کنند. در عوض، وضعیت مدل حتی پس از تحویل رویداد نیز در حال اجرا باقی می‌ماند.

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

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

توجه: اگرچه این خطاها در مستندات HAL API معتبر شناخته شده‌اند، اما در مورد زمان و وضعیت این کدهای خطا و نحوه‌ی بازیابی خطای مورد انتظار ابهام وجود دارد. از این رو، اندروید ۱۱، انطباق دقیق‌تری را در زمان اجرا با پیاده‌سازی‌های Sound Trigger HAL نسبت به نسخه‌های پایین‌تر اندروید الزامی می‌کند.