ध्वनि ट्रिगर

साउंड ट्रिगर सुविधा ऐप्स को कम-शक्ति और गोपनीयता-संवेदनशील तरीके से हॉटवर्ड जैसी कुछ ध्वनिक घटनाओं को सुनने की क्षमता प्रदान करती है। साउंड ट्रिगर के उदाहरण उपयोग के मामले असिस्टेंट और नाउ प्लेइंग हैं।

यह पृष्ठ साउंड ट्रिगर आर्किटेक्चर और इसके एचएएल (हार्डवेयर एब्स्ट्रैक्शन लेयर) इंटरफ़ेस का अवलोकन देता है।

ध्वनि ट्रिगर स्टैक

साउंड ट्रिगर सबसिस्टम परतों में बनाया गया है जैसा चित्र 1 में दिखाया गया है:

चित्र 1: ध्वनि ट्रिगर स्टैक

निम्नलिखित सूची चित्र 1 में दिखाई गई प्रत्येक परत का अधिक विस्तार से वर्णन करती है:

• HAL परत (हरे रंग में) में विक्रेता विशिष्ट कोड होता है जो साउंड ट्रिगर HAL (STHAL) इंटरफ़ेस को लागू करता है।

  ध्यान दें: विरासत HAL के कार्यान्वयन के आसपास एडॉप्टर के बजाय STHAL इंटरफ़ेस के प्रत्यक्ष कार्यान्वयन की अनुशंसा की जाती है।

• SoundTriggerMiddleware (पीले रंग में) HAL इंटरफ़ेस के ऊपर स्थित है। यह एचएएल के साथ संचार करता है और विभिन्न ग्राहकों के बीच एचएएल को साझा करने, लॉगिंग, अनुमतियों को लागू करने और पुराने एचएएल संस्करणों के साथ संगतता को संभालने जैसी कार्यात्मकताओं के लिए जिम्मेदार है।

• SoundTriggerService (नीले रंग में) सिस्टम मिडलवेयर के ऊपर रहता है। यह अन्य सिस्टम सुविधाओं जैसे टेलीफोनी और बैटरी इवेंट के साथ एकीकरण की सुविधा प्रदान करता है। यह अद्वितीय आईडी द्वारा अनुक्रमित ध्वनि मॉडल का एक डेटाबेस भी रखता है।

• SoundTriggerService लेयर के ऊपर, स्टैक (भूरे रंग में) असिस्टेंट और जेनेरिक ऐप्स के लिए विशिष्ट सुविधाओं को अलग-अलग हैंडल करता है।

साउंड ट्रिगर स्टैक का कार्य अलग-अलग घटनाओं को वितरित करना है जो ध्वनिक, ट्रिगर घटनाओं का प्रतिनिधित्व करते हैं। ज्यादातर मामलों में, साउंड ट्रिगर स्टैक ऑडियो से संबंधित नहीं है। ट्रिगर ईवेंट प्राप्त होने पर, ऐप्स को ऑडियो फ्रेमवर्क के माध्यम से AudioRecord ऑब्जेक्ट खोलकर, ईवेंट के समय के आसपास की वास्तविक ऑडियो स्ट्रीम तक पहुंच मिलती है। साउंड ट्रिगर एचएएल एपीआई ट्रिगर इवेंट के साथ एक हैंडल प्रदान करता है जिसका उपयोग ऑडियो फ्रेमवर्क के साथ किया जाता है। इसलिए, चूंकि साउंड ट्रिगर एचएएल और ऑडियो एचएएल हुड के नीचे जुड़े हुए हैं, वे आम तौर पर एक प्रक्रिया साझा करते हैं।

नोट: चूंकि मॉडल और डेटा प्रकार साउंड ट्रिगर सबसिस्टम में ढांचे के लिए अपारदर्शी हैं, इसलिए यह उम्मीद की जाती है कि ऐप्स और एचएएल कार्यान्वयन एक "छिपे हुए अनुबंध" को बनाए रखें, यानी, उन डेटा प्रकारों की वास्तविक सामग्री, प्रारूप और शब्दार्थ पर सहमति हो। ऊपर। इसलिए, साउंड ट्रिगर का उपयोग करने वाले ऐप्स का उद्देश्य स्वतंत्र डेवलपर्स के बजाय विक्रेता द्वारा प्रदान किया जाना है।

ध्वनि ट्रिगर एचएएल इंटरफ़ेस

साउंड ट्रिगर एचएएल (STHAL) इंटरफ़ेस साउंड ट्रिगर स्टैक का विक्रेता विशिष्ट हिस्सा है और यह हॉटवर्ड और अन्य ध्वनियों की हार्डवेयर पहचान को संभालता है। STHAL एक या एक से अधिक इंजन प्रदान करता है, जिनमें से प्रत्येक एक विशिष्ट श्रेणी की ध्वनियों का पता लगाने के लिए डिज़ाइन किया गया एक अलग एल्गोरिदम चलाता है। जब STHAL किसी ट्रिगर का पता लगाता है, तो यह फ्रेमवर्क को एक ईवेंट भेजता है और फिर पता लगाना बंद कर देता है।

STHAL इंटरफ़ेस /hardware/interfaces/soundtrigger/ के अंतर्गत निर्दिष्ट है।

ISoundTriggerHw इंटरफ़ेस एक निश्चित समय पर एक या अधिक डिटेक्शन सत्र चलाने और ध्वनिक घटनाओं को सुनने की क्षमता का समर्थन करता है। ISoundTriggerHw.getProperties() पर कॉल कार्यान्वयन विवरण और क्षमताओं वाली एक Properties संरचना लौटाती है।

सत्र की स्थापना का मूल प्रवाह चित्र 2 में निम्नानुसार समझाया गया है:

चित्र 2: STHAL राज्य आरेख

निम्नलिखित चरण प्रत्येक राज्य का अधिक विस्तार से वर्णन करते हैं:

1. HAL क्लाइंट loadSoundModel() या loadPhraseSoundModel() का उपयोग करके एक मॉडल लोड करता है। प्रदान किया गया मॉडल ऑब्जेक्ट इंगित करता है कि किस कार्यान्वयन-विशिष्ट पहचान एल्गोरिदम (इंजन) का उपयोग करना है, साथ ही इस एल्गोरिदम के लिए लागू पैरामीटर भी। सफल होने पर, ये विधियाँ एक हैंडल लौटाती हैं जिसका उपयोग बाद की कॉलों में इस मॉडल को संदर्भित करने के लिए किया जाता है।

2. एक बार मॉडल सफलतापूर्वक लोड हो जाने के बाद, एचएएल क्लाइंट पता लगाना शुरू करने के लिए startRecognition() को कॉल करता है। निम्न में से कोई एक घटना घटित होने तक मान्यता पृष्ठभूमि में चलती रहती है:

   1. इस मॉडल पर एक stopRecognition() बुलाया गया है।
   2. एक पता चला है.
   3. संसाधन की कमी के कारण जांच रोक दी जाती है, उदाहरण के लिए, जब उच्च प्राथमिकता वाला उपयोग मामला शुरू किया गया हो।

   बाद के दो मामलों में, एक मान्यता ईवेंट कॉलबैक इंटरफ़ेस के माध्यम से भेजा जाता है जिसे लोड होने पर एचएएल क्लाइंट द्वारा पंजीकृत किया जाता है। सभी मामलों में, इनमें से किसी भी घटना के घटित होने के बाद, पता लगाना निष्क्रिय हो जाता है और अधिक पहचान कॉलबैक की अनुमति नहीं होती है।

   उसी मॉडल को बाद में फिर से शुरू किया जा सकता है, और इस प्रक्रिया को आवश्यकतानुसार कई बार दोहराया जा सकता है।

3. अंत में, एक निष्क्रिय मॉडल जिसकी अब आवश्यकता नहीं है, एचएएल क्लाइंट द्वारा unloadModel() के माध्यम से अनलोड किया जाता है।

नोट: जब कोई मॉडल शुरू किया जाता है, तो एचएएल क्लाइंट एक मजबूर पहचान घटना उत्पन्न करने के लिए forceRecognitionEvent() को कॉल कर सकता है। लौटाया गया इवेंट सामान्य पहचान इवेंट के समान है, लेकिन इसका स्टेटस फ़ील्ड FORCED पर सेट है। इस तरह की मान्यता की घटनाएँ स्वचालित रूप से मान्यता को नहीं रोकती हैं। इसके बजाय, ईवेंट वितरित होने के बाद भी मॉडल स्थिति चालू रहती है।

एचएएल त्रुटियों को संभालें

ड्राइवर कार्यान्वयन के बीच विश्वसनीय और सुसंगत व्यवहार सुनिश्चित करने के लिए, एंड्रॉइड 11 में, एचएएल से लौटाए गए किसी भी गैर-सफल त्रुटि कोड को प्रोग्रामिंग त्रुटियों के रूप में माना जाता है, जिससे पुनर्प्राप्ति के लिए एचएएल प्रक्रिया को पुनरारंभ करने की आवश्यकता होती है। यह एक अंतिम उपाय पुनर्प्राप्ति रणनीति है और उम्मीद यह है कि उचित कार्य प्रणाली में ऐसे मामले घटित नहीं होंगे।

नोट: हालाँकि इन त्रुटियों को एचएएल एपीआई दस्तावेज़ में वैध बताया जा रहा है, लेकिन इस बारे में अस्पष्टता है कि ये त्रुटि कोड कब और किस स्थिति में लौटाए जाते हैं और अपेक्षित त्रुटि पुनर्प्राप्ति प्रक्रिया क्या है। इसलिए, एंड्रॉइड 11 एंड्रॉइड के निचले संस्करणों की तुलना में रनटाइम पर साउंड ट्रिगर एचएएल कार्यान्वयन के सख्त अनुरूपता को अनिवार्य करता है।