תכונת ה-Sound Trigger מספקת לאפליקציות את היכולת להאזין לאירועים אקוסטיים מסוימים, כמו מילות עזר, באופן דל עוצמה ורגישה לפרטיות. מקרי שימוש לדוגמה של Sound Trigger הם Assistant ו- Now Playing.
דף זה נותן סקירה כללית של ארכיטקטורת Sound Trigger וממשק ה-HAL (Hardware Abstraction Layer) שלה.
ערימת הפעלת סאונד
תת-מערכת ה-Sound Trigger בנויה בשכבות כפי שמוצג באיור 1:
איור 1: ערימת הפעלת סאונד
הרשימה הבאה מתארת כל שכבה המוצגת באיור 1 ביתר פירוט:
שכבת HAL (בירוק) מכילה את הקוד הספציפי לספק אשר מיישם את ממשק Sound Trigger HAL (STHAL).
תוכנת
SoundTriggerMiddleware
(בצהוב) נמצאת מעל ממשק HAL. הוא מתקשר עם ה-HAL ואחראי לפונקציונליות כגון שיתוף ה-HAL בין לקוחות שונים, רישום, אכיפת הרשאות וטיפול בתאימות עם גרסאות HAL ישנות יותר.מערכת
SoundTriggerService
(בכחול) נמצאת מעל תוכנת האמצע. זה מקל על אינטגרציה עם תכונות מערכת אחרות, כגון טלפוניה ואירועי סוללה. הוא גם מתחזק מסד נתונים של דגמי סאונד, המצוידים באינדקס על ידי מזהים ייחודיים.מעל שכבת
SoundTriggerService
, המחסנית (בחום) מטפלת בתכונות ספציפיות ל-Assistant ולאפליקציות גנריות בנפרד.
הפונקציה של ערימת ה-Sound Trigger היא לספק אירועים נפרדים המייצגים אירועי טריגר אקוסטיים. ברוב המקרים, ערימת ה-Sound Trigger אינה עוסקת באודיו. עם קבלת אירועי הטריגר, אפליקציות מקבלים גישה לזרם האודיו בפועל, המקיף את זמן האירועים, על ידי פתיחת אובייקט AudioRecord
דרך מסגרת האודיו. ממשקי ה-Sound Trigger HAL מספקים טיפול באירוע המופעל המשמש עם מסגרת האודיו. לפיכך, מכיוון שה-Sound Trigger HAL ו- Audio HAL מחוברים מתחת למכסה המנוע, הם בדרך כלל חולקים תהליך.
ממשק Sound Trigger HAL
ממשק Sound Trigger HAL (STHAL) הוא החלק הספציפי של הספק בערימת ה-Sound Trigger והוא מטפל בזיהוי חומרה של מילות הפעלה וצלילים אחרים. STHAL מספק מנוע אחד או יותר כאשר כל אחד מהם מפעיל אלגוריתם אחר שנועד לזהות סוג מסוים של צלילים. כאשר STHAL מזהה טריגר, הוא שולח אירוע למסגרת ולאחר מכן מפסיק את הזיהוי.
ממשק STHAL מצוין תחת /hardware/interfaces/soundtrigger/
.
ממשק ISoundTriggerHw
תומך ביכולת להפעיל סשן זיהוי אחד או יותר בזמן נתון ולהאזין לאירועים אקוסטיים. קריאה ל- ISoundTriggerHw.getProperties()
מחזירה מבנה Properties
המכיל תיאור ויכולות יישום.
הזרימה הבסיסית של הגדרת הפעלה מוסברת כדלקמן באיור 2:
איור 2: דיאגרמת מצב STHAL
השלבים הבאים מתארים כל מדינה ביתר פירוט:
לקוח HAL טוען מודל באמצעות
loadSoundModel()
אוloadPhraseSoundModel()
. אובייקט המודל שסופק מציין באיזה אלגוריתם (מנוע) זיהוי ספציפי ליישום, כמו גם את הפרמטרים הרלוונטיים לאלגוריתם זה. לאחר הצלחה, שיטות אלה מחזירות ידית אחיזה המשמשת להתייחסות למודל זה בקריאות עוקבות.לאחר שהמודל נטען בהצלחה, לקוח HAL קורא ל-
startRecognition()
כדי להתחיל בזיהוי. הזיהוי ממשיך לפעול ברקע עד שמתרחש אחד מהאירועים הבאים:-
stopRecognition()
נקרא במודל זה. - התרחש זיהוי.
- הזיהוי מבוטל עקב אילוצי משאבים, למשל, כאשר החל מקרה שימוש בעדיפות גבוהה יותר.
בשני המקרים האחרונים, אירוע זיהוי נשלח באמצעות ממשק ה-callback שנרשם על ידי לקוח HAL בעת הטעינה. בכל המקרים, לאחר שהתרחש כל אחד מהאירועים הללו, הזיהוי הופך ללא פעיל ולא מותרות יותר התקשרויות זיהוי.
ניתן להתחיל שוב את אותו דגם במועד מאוחר יותר, וניתן לחזור על תהליך זה כמה פעמים לפי הצורך.
-
לבסוף, מודל לא פעיל שאין בו צורך עוד נפרק על ידי לקוח HAL באמצעות
unloadModel()
.
טיפול בשגיאות HAL
כדי להבטיח התנהגות אמינה ועקבית בין יישומי מנהלי התקנים, באנדרואיד 11, כל קודי שגיאה לא מוצלחים המוחזרים מה-HAL מטופלים כשגיאות תכנות, שההתאוששות מהן דורשת הפעלה מחדש של תהליך HAL. זוהי אסטרטגיית התאוששות של מוצא אחרון והציפייה היא שמקרים כאלה לא יתרחשו במערכת שפועלת כהלכה.