एंड्रॉइड 10 उपयोगकर्ता अनुभव को बेहतर बनाता है जिसके लिए एक से अधिक सक्रिय ऑडियो कैप्चर की आवश्यकता होती है, उदाहरण के लिए, यदि उपयोगकर्ता एक्सेसिबिलिटी सेवा द्वारा प्रदान किए गए वॉयस कमांड के साथ वीओआईपी कॉल या वीडियो रिकॉर्डर को नियंत्रित करना चाहता है।
ऑडियो ढांचा उस नीति को लागू करता है जो केवल कुछ विशेषाधिकार प्राप्त ऐप्स को नियमित ऐप्स के साथ समवर्ती रूप से कैप्चर करने की इजाजत देता है।
किसी एप्लिकेशन को कैप्चरिंग शुरू करने से रोकने के बजाय उसके कैप्चर किए गए ऑडियो को शांत करके समवर्ती नीति लागू की जाती है। यह फ्रेमवर्क को सक्रिय कैप्चर उपयोग मामलों की संख्या और प्रकारों में परिवर्तनों को गतिशील रूप से संबोधित करने की अनुमति देता है, बिना किसी ऐप को कैप्चरिंग शुरू करने से रोकने के लिए जहां यह किसी अन्य ऐप द्वारा कैप्चरिंग समाप्त करने के बाद माइक्रोफ़ोन तक पूर्ण पहुंच पुनर्प्राप्त कर सकता है।
ऑडियो एचएएल और ऑडियो सबसिस्टम का परिणाम यह है कि उन्हें एक साथ कई सक्रिय इनपुट स्ट्रीम का समर्थन करना चाहिए, भले ही कुछ मामलों में, केवल एक स्ट्रीम एक सक्रिय क्लाइंट को नॉन-साइलेंट ऑडियो प्रदान कर रही हो।
सीडीडी आवश्यकताएं
समवर्ती कैप्चर समर्थन के लिए आवश्यकताओं के लिए सीडीडी देखें।
ऑडियो HAL . से स्थितियों को कैप्चर करें
एक समवर्ती कैप्चर परिदृश्य सक्रिय इनपुट स्ट्रीम की संख्या, इनपुट डिवाइस चयन, या प्रीप्रोसेसिंग कॉन्फ़िगरेशन के संदर्भ में विभिन्न स्थितियों में परिणाम कर सकता है।
निम्नलिखित के बीच संगामिति हो सकती है:
- एप्लिकेशन प्रोसेसर (एपी) से कई इनपुट स्ट्रीम
- इनपुट स्ट्रीम और वॉयस कॉल
- इनपुट स्ट्रीम और एक ऑडियो डीएसपी जो लो-पावर हॉटवर्ड डिटेक्शन को लागू करता है
एपी इनपुट स्ट्रीम की समवर्ती गतिविधि
ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल audio_policy_configuration.xml का उपयोग ऑडियो फ्रेमवर्क द्वारा यह निर्धारित करने के लिए किया जाता है कि एक साथ कितनी इनपुट स्ट्रीम खोली और सक्रिय की जा सकती हैं।
कम से कम, ऑडियो HAL को खुले और सक्रिय कॉन्फ़िगरेशन फ़ाइल में सूचीबद्ध प्रत्येक इनपुट प्रोफ़ाइल ( mixPort ऑफ़ रोल sink ) के कम से कम एक उदाहरण का समर्थन करना चाहिए।
डिवाइस चयन
जब कई सक्रिय क्लाइंट एक ही एचएएल इनपुट स्ट्रीम से जुड़े होते हैं, तो फ्रेमवर्क इस इनपुट स्ट्रीम के लिए उपयोग के मामले की प्राथमिकता के आधार पर उपयुक्त डिवाइस का चयन करता है।
जब कई इनपुट स्ट्रीम सक्रिय होते हैं, तो प्रत्येक स्ट्रीम में एक अलग डिवाइस चयन हो सकता है।
यदि तकनीक संगत है, तो यह अनुशंसा की जाती है कि ऑडियो एचएएल और सबसिस्टम अलग-अलग उपकरणों से अलग-अलग स्ट्रीम को कैप्चर करने की अनुमति दें, जैसे कि ब्लूटूथ हेडसेट और बिल्ट-इन माइक।
यदि कोई असंगति है (उदाहरण के लिए दो डिवाइस एक ही डिजिटल ऑडियो इंटरफ़ेस या बैक एंड साझा करते हैं) तो ऑडियो एचएएल को यह चुनना होगा कि कौन सी स्ट्रीम डिवाइस चयन को नियंत्रित करती है।
इस मामले में:
- परिणामी स्थिति सुसंगत होनी चाहिए और उसी परिदृश्य को दोहराए जाने पर समान डिवाइस चयन की पेशकश करनी चाहिए।
- जब समवर्ती स्थिति समाप्त हो जाती है, तो शेष सक्रिय स्ट्रीम को इस स्ट्रीम पर प्रारंभिक रूप से अनुरोधित डिवाइस पर रूट किया जाना चाहिए।
यदि सक्रिय उपयोग के मामलों के बीच ऑडियो एचएएल द्वारा प्राथमिकता क्रम को परिभाषित किया गया है, तो उसी क्रम का पालन करें जैसा कि frameworks/av/services/audiopolicy/common/include/policy.h में source_priority() में पाया गया है।
पूर्व प्रसंस्करण चयन
ऑडियो फ्रेमवर्क addEffect() या removeEffect() HAL विधियों का उपयोग करके इनपुट स्ट्रीम पर प्रीप्रोसेसिंग का अनुरोध कर सकता है।
किसी दिए गए इनपुट स्ट्रीम पर प्रीप्रोसेसिंग के लिए, ऑडियो फ्रेमवर्क केवल इनपुट स्ट्रीम पर उच्चतम-प्राथमिकता वाले सक्रिय उपयोग के मामले के अनुरूप कॉन्फ़िगरेशन को सक्षम करता है। हालांकि, उपयोग केस सक्रियण और निष्क्रियता के दौरान कुछ ओवरलैप हो सकते हैं, जिससे एक साथ दो सक्रिय प्रक्रियाएं (उदाहरण के लिए, इको कैंसेलर के दो उदाहरण) एक ही इनपुट स्ट्रीम पर चलती हैं। इस मामले में, एचएएल कार्यान्वयन चुनता है कि कौन सा अनुरोध स्वीकार किया जाता है; यह सक्रिय अनुरोधों का ट्रैक रखता है और किसी भी प्रक्रिया के अक्षम होने पर सही स्थिति को पुनर्स्थापित करता है।
जब कई कैप्चर स्ट्रीम एक साथ सक्रिय होती हैं, तो अलग-अलग स्ट्रीम पर अलग-अलग प्रीप्रोसेसिंग अनुरोध चलाए जा सकते हैं।
एचएएल और ऑडियो सबसिस्टम कार्यान्वयन को अलग-अलग धाराओं पर अलग-अलग प्री प्रोसेसिंग लागू करने की अनुमति देनी चाहिए, भले ही वे एक ही इनपुट डिवाइस साझा करते हों। यानी प्राइमरी कैप्चर सोर्स से स्ट्रीम को डीमक्स करने के बाद प्री प्रोसेसिंग लागू की जानी चाहिए।
यदि किसी दिए गए ऑडियो सबसिस्टम पर तकनीकी कारणों से यह संभव नहीं है, तो ऑडियो HAL को डिवाइस चयन में सूचीबद्ध लोगों के समान प्राथमिकता वाले नियम लागू करने चाहिए।
एपी . से समवर्ती वॉयस कॉल और कैप्चर
वॉयस कॉल सक्रिय होने पर एपी से कैप्चर हो सकता है। एंड्रॉइड 10 में यह स्थिति नई नहीं है और सीधे समवर्ती कैप्चर सुविधा से संबंधित नहीं है, लेकिन इस परिदृश्य के लिए दिशानिर्देशों का उल्लेख करना उपयोगी है।
कॉल के दौरान AP से दो अलग-अलग प्रकार के कैप्चर की आवश्यकता होती है।
कैप्चरिंग कॉल RX और TX
RX और TX कॉल कैप्चर करना ऑडियो स्रोत AudioSource.VOICE_UPLINK या AudioSource.VOICE_DOWNLINK , और/या डिवाइस AudioDevice.IN_TELEPHONY_RX के उपयोग से ट्रिगर होता है।
ऑडियो HALs को डिवाइस AudioDevice.IN_TELEPHONY_RX से उपलब्ध रूट के साथ इनपुट प्रोफाइल ( mixPort ऑफ़ रोल sink ) पर प्रदर्शित होना चाहिए।
जब कोई कॉल कनेक्ट होती है (ऑडियो मोड AudioMode.IN_CALL है), तो डिवाइस AudioDevice.IN_TELEPHONY_RX से कम से कम एक सक्रिय कैप्चर स्ट्रीम होना संभव होना चाहिए।
कॉल सक्रिय होने पर इनपुट डिवाइस से कैप्चर करना
जब कोई कॉल सक्रिय होती है (ऑडियो मोड AudioMode.IN_CALL है), तो AP से इनपुट स्ट्रीम को खोलना और सक्रिय करना संभव होना चाहिए जैसा कि AP इनपुट स्ट्रीम की समवर्ती गतिविधि अनुभाग में निर्दिष्ट है।
हालांकि, डिवाइस के चयन और प्री-प्रोसेसिंग की प्राथमिकता हमेशा वॉयस कॉल द्वारा संचालित की जानी चाहिए, अगर एपी इनपुट स्ट्रीम के अनुरोधों के साथ कोई विरोध होता है।
डीएसपी और एपी से समवर्ती कब्जा
जब ऑडियो सबसिस्टम में कम-शक्ति ऑडियो संदर्भ या हॉटवर्ड डिटेक्शन फ़ंक्शंस का समर्थन करने वाला डीएसपी होता है, तो कार्यान्वयन को एपी और ऑडियो डीएसपी से समवर्ती कैप्चर का समर्थन करना चाहिए। इसमें प्रारंभिक डिटेक्शन चरण के दौरान डीएसपी द्वारा कैप्चर और AudioSource.HOTWORD के साथ एपी द्वारा कैप्चर दोनों शामिल हैं। डीएसपी द्वारा डिटेक्शन ट्रिगर होने के बाद हॉटवर्ड।
यह कार्यान्वयन डिस्क्रिप्टर के माध्यम से ध्वनि ट्रिगर एचएएल द्वारा रिपोर्ट किए गए समवर्ती कैप्चर ध्वज द्वारा परिलक्षित होना चाहिए: ISoundTriggerHw.Properties.concurrentCapture = true ।
ऑडियो एचएएल को फ्लैग AudioInputFlag.HW_HOTWORD द्वारा पहचाने गए हॉटवर्ड कैप्चर के लिए विशिष्ट प्रोफ़ाइल को भी एक्सपोज़ और इनपुट करना चाहिए। कार्यान्वयन को इस प्रोफ़ाइल पर कम से कम ध्वनि मॉडल की संख्या के बराबर कई धाराओं को खोलने और सक्रिय करने का समर्थन करना चाहिए जिन्हें ध्वनि ट्रिगर एचएएल द्वारा समवर्ती रूप से लोड किया जा सकता है।
अन्य इनपुट प्रोफाइल सक्रिय होने पर इस इनपुट प्रोफाइल से कैप्चर करना संभव होना चाहिए।
सहायक कार्यान्वयन के लिए निहितार्थ
डेटा उपयोग और उपयोगकर्ता अधिसूचना पर आवश्यकताएँ
चूंकि समवर्ती माइक उपयोग, यदि दुरुपयोग किया जाता है, तो उपयोगकर्ता का निजी डेटा लीक हो सकता है, हमें निम्नलिखित शर्तों और गारंटियों को विशेषाधिकार प्राप्त प्रीलोडेड ऐप्स पर लागू करने की आवश्यकता है जो सहायक भूमिका निभाने के लिए कहते हैं।
- जब तक उपयोगकर्ता Assistant के साथ इंटरैक्ट नहीं कर रहा है, तब तक माइक्रोफ़ोन के ज़रिए इकट्ठा किया गया डेटा डिवाइस से बाहर नहीं जाना चाहिए। उदाहरण के लिए, हॉटवर्ड ट्रिगर होने के बाद।
- समवर्ती रूप से सुनने वाले अनुप्रयोगों को हॉटवर्ड का पता चलने के बाद उपयोगकर्ता को दृश्य संकेत प्रदान करने चाहिए। इससे उपयोगकर्ताओं को यह समझने में मदद मिलती है कि आगे की बातचीत एक अलग ऐप, जैसे कि सहायक के माध्यम से होगी।
- उपयोगकर्ताओं के पास माइक्रोफ़ोन या सहायक ट्रिगर को बंद करने की क्षमता होनी चाहिए।
- जब ऑडियो रिकॉर्डिंग संग्रहीत की जाती हैं, तो उपयोगकर्ताओं के पास किसी भी समय रिकॉर्डिंग तक पहुंचने, समीक्षा करने और हटाने की क्षमता होनी चाहिए।
Android 10 के लिए कार्यात्मक सुधार
सहायक एक दूसरे को ब्लॉक नहीं कर रहे हैं
एंड्रॉइड 9 या उससे कम पर, जब डिवाइस पर हमेशा दो सहायक होते हैं, तो उनमें से केवल एक ही इसके हॉटवर्ड को सुन सकता है। इसलिए, दो सहायकों के बीच स्विच करने की आवश्यकता थी। एंड्रॉइड 10 में, डिफ़ॉल्ट सहायक अन्य सहायक के साथ समवर्ती रूप से सुन सकता है। यह दोनों सहायकों वाले उपयोगकर्ताओं के लिए बहुत आसान अनुभव प्रदान करता है।
माइक खुला रखने वाले ऐप्स
जब शाज़म या वेज़ जैसे ऐप माइक को खुला रखते हैं, तब भी डिफ़ॉल्ट सहायक हॉटवर्ड को सुन सकता है।
गैर-डिफ़ॉल्ट सहायक ऐप्स के लिए, Android 10 के व्यवहार में कोई बदलाव नहीं किया गया है।
नमूना ऑडियो एचएएल कार्यान्वयन
इस दस्तावेज़ में दिशानिर्देशों का अनुपालन करने वाले ऑडियो एचएएल कार्यान्वयन का एक उदाहरण एओएसपी में पाया जा सकता है।