הפעלה באמצעות קול

התכונה 'טריגר קולי' מאפשרת לאפליקציות להאזין לאירועים אקוסטיים מסוימים, כמו מילות הפעלה, בצורה חסכונית באנרגיה ושומרת על הפרטיות. דוגמאות לתרחישי שימוש בטריגרים של צלילים: Assistant ו'מה מושמע עכשיו'.

בדף הזה יש סקירה כללית של ארכיטקטורת ההפעלה הקולית וממשק ה-HAL שלה (שכבת הפשטה של חומרה).

Sound Trigger stack

מערכת המשנה Sound Trigger בנויה בשכבות, כמו שמוצג באיור 1:

sound_trigger_stack

איור 1: מחסנית Sound Trigger

ברשימה הבאה מפורט כל אחד מהרכיבים שמוצגים באיור 1:

  • שכבת ה-HAL (בירוק) מכילה את הקוד הספציפי לספק שמיישם את הממשק Sound Trigger HAL‏ (STHAL).

  • ‫SoundTriggerMiddleware (בצהוב) נמצא מעל ממשק HAL. הוא מתקשר עם HAL ואחראי לפונקציות כמו שיתוף HAL בין לקוחות שונים, רישום ביומן, אכיפת הרשאות וטיפול בתאימות לגרסאות ישנות יותר של HAL.

  • המערכת SoundTriggerService (בכחול) נמצאת מעל תוכנת הביניים. הוא מאפשר שילוב עם תכונות אחרות של המערכת, כמו טלפוניה ואירועים שקשורים לסוללה. בנוסף, היא מתחזקת מסד נתונים של מודלים של צלילים, שממוינים לפי מזהים ייחודיים.

  • מעל שכבת SoundTriggerService, המערך (בצבע חום) מטפל בתכונות ספציפיות ל-Assistant ובאפליקציות גנריות בנפרד.

תפקיד מחסנית Sound Trigger הוא להעביר אירועים נפרדים שמייצגים אירועים אקוסטיים של טריגר. ברוב המקרים, מחסנית Sound Trigger לא מטפלת באודיו. כשמתקבלים אירועים של טריגר, האפליקציות מקבלות גישה לזרם האודיו בפועל, שמתרחש סביב הזמן של האירועים, על ידי פתיחת אובייקט AudioRecord דרך מסגרת האודיו. ממשקי ה-API של Sound Trigger HAL מספקים נקודת אחיזה עם האירוע שהופעל, שמשמשת עם Audio Framework. לכן, מכיוון ש-Sound Trigger HAL ו-Audio HAL מחוברים מתחת לפני השטח, הם בדרך כלל חולקים תהליך.

ממשק HAL של הפעלת קול

ממשק ה-HAL של Sound Trigger ‏ (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. הזיהוי מבוטל בגלל מגבלות משאבים, למשל, כשמתחיל תרחיש שימוש עם עדיפות גבוהה יותר.

    בשני המקרים האחרונים, אירוע זיהוי נשלח דרך ממשק הקריאה החוזרת (callback) שרשום על ידי לקוח HAL בזמן הטעינה. בכל המקרים האלה, אחרי שאחד מהאירועים האלה מתרחש, הזיהוי מושבת ולא ניתן יותר להשתמש בקריאות חוזרות לזיהוי.

    אפשר להפעיל מחדש את אותו מודל במועד מאוחר יותר, ולחזור על התהליך הזה כמה פעמים שצריך.

  3. לבסוף, מודל לא פעיל שכבר לא נחוץ מוסר מהזיכרון על ידי לקוח HAL באמצעות unloadModel().

טיפול בשגיאות HAL

כדי להבטיח התנהגות אמינה ועקבית בין יישומי מנהלי התקנים, ב-Android 11, כל קודי שגיאה שאינם מציינים הצלחה ומוחזרים מ-HAL נחשבים לשגיאות תכנות, והתיקון שלהן מחייב הפעלה מחדש של תהליך HAL. זו אסטרטגיית שחזור שמשתמשים בה כמוצא אחרון, וההנחה היא שמקרים כאלה לא יקרו במערכת שעובדת בצורה תקינה.