טריגר צליל

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

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

סטאק של טריגרים של קול

מערכת המשנה של הפעלת האודיו מורכבת משכבות, כפי שמוצג באיור 1:

sound_trigger_stack

איור 1: סטאק של טריגרים של צלילים

ברשימה הבאה מתוארים כל השכבות שמוצגות באיור 1:

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

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

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

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

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

ממשק HAL של Sound Trigger

ממשק ה-HAL (STHAL) של Sound Trigger הוא החלק הספציפי לספק ב-Sound Trigger stack, והוא מטפל בזיהוי חומרה של מילות מפתח וצלילים אחרים. STHAL מספק מנוע אחד או יותר, ובכל אחד מהם פועל אלגוריתם שונה שנועד לזהות סוג ספציפי של צלילים. כש-STHAL מזהה טריגר, הוא שולח אירוע למסגרת ואז מפסיק את הזיהוי.

ממשק STHAL מצוין בקטע /hardware/interfaces/soundtrigger/.

הממשק ISoundTriggerHw תומך באפשרות להפעיל סשן זיהוי אחד או יותר בזמן נתון ולהאזין לאירועים אקוסטיים. קריאה ל-ISoundTriggerHw.getProperties() מחזירה מבנה Properties שמכיל את היכולות ואת תיאור ההטמעה.

התהליך הבסיסי להגדרת סשן מוסבר באיור 2:

sthal_state

איור 2: תרשים המצבים של STHAL

השלבים הבאים מתארים כל מדינה בפירוט:

  1. לקוח HAL טוען מודל באמצעות loadSoundModel() או loadPhraseSoundModel(). אובייקט המודל שסופק מציין את אלגוריתם הזיהוי (המנוע) הספציפי להטמעה שבו צריך להשתמש, וגם את הפרמטרים הרלוונטיים לאלגוריתם הזה. אם הפעולה מסתיימת בהצלחה, השיטות האלה מחזירות טיפולן (handle) שמשמש להפניה למודל הזה בקריאות הבאות.

  2. אחרי שהמודל נטען בהצלחה, לקוח ה-HAL קורא ל-startRecognition() כדי להתחיל את הזיהוי. זיהוי הפנים ממשיך לפעול ברקע עד שאחד מהאירועים הבאים מתרחש:

    1. בוצעה קריאה ל-stopRecognition() במודל הזה.
    2. התרחש זיהוי.
    3. הזיהוי מבוטל בגלל מגבלות משאבים, למשל כשהופעל תרחיש לדוגמה בעדיפות גבוהה יותר.

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

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

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

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

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