Android 10 रिलीज़ में, ऑडियो
नीति मैनेजर को फिर से तैयार किया गया है. इससे, वाहन से जुड़े कॉम्प्लेक्स इस्तेमाल के उदाहरणों को बेहतर तरीके से इस्तेमाल करने में मदद मिलेगी:
OEM के हिसाब से रूटिंग की रणनीतियां.
एक जैसे वॉल्यूम कर्व का इस्तेमाल करके, लेगसी स्ट्रीम टाइप के ग्रुप के लिए, पसंद के मुताबिक बनाए जा सकने वाले वॉल्यूम ग्रुप.
हार्ड कोड होने के बजाय, ऑडियो नीति इंजन की ओर से बताई गई रूटिंग की रणनीतियां.
ऑडियो नीति इंजन की मदद से मैनेज किए जाने वाले वॉल्यूम कर्व और ग्रुप.
आम कोड और कॉन्फ़िगर किए जा सकने वाले कोड के बीच, आने वाले समय में होने वाले बंटवारे की तैयारी के लिए, इंटरनल रीफ़ैक्टरिंग की जा रही है. साथ ही, ऑडियो डिवाइस को बेहतर तरीके से मैनेज करने की सुविधा भी दी जा रही है. उदाहरण के लिए, नीति के नियमों में डिवाइस के टाइप के साथ-साथ, सभी डिवाइस प्रॉपर्टी का इस्तेमाल करना.
Android 7.0 में, ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल फ़ॉर्मैट (एक्सएमएल) को शामिल किया गया है. इससे, ऑडियो टोपोलॉजी के बारे में जानकारी मिलती है.
आपके प्रॉडक्ट पर मौजूद ऑडियो डिवाइस की जानकारी देने के लिए, device/<company>/<device>/audio/audio_policy.conf का इस्तेमाल करना ज़रूरी है. पिछली Android रिलीज़ के लिए, device/samsung/tuna/audio/audio_policy.conf में Galaxy Nexus ऑडियो हार्डवेयर का एक उदाहरण देखा जा सकता है. हालांकि, CONF एक आसान और मालिकाना फ़ॉर्मैट है. यह टीवी और ऑटोमोबाइल जैसे वर्टिकल के लिए मुश्किल चीज़ों के बारे में बताने के लिए ही सीमित है.
Android 7.0 ने audio_policy.conf को बंद कर दिया. साथ ही, एक्सएमएल फ़ाइल फ़ॉर्मैट का इस्तेमाल करके ऑडियो टोपोलॉजी के बारे में बताने में सहायता जोड़ी गई. एक्सएमएल फ़ाइल फ़ॉर्मैट को इंसान पढ़ सकते हैं. इसमें कई तरह के एडिटिंग और पार्स करने वाले टूल मौजूद हैं. साथ ही, इसमें मुश्किल ऑडियो टोटोलॉजी की जानकारी देने के लिए, ज़रूरत के हिसाब से सुविधा दी गई है. Android 7.0, कॉन्फ़िगरेशन फ़ाइलों के एक्सएमएल फ़ॉर्मैट को चुनने के लिए,
USE_XML_AUDIO_POLICY_CONF बिल्ड फ़्लैग का इस्तेमाल करता है.
एक्सएमएल फ़ॉर्मैट के फ़ायदे
CONF फ़ाइल की तरह, एक्सएमएल फ़ाइल में भी आउटपुट और इनपुट स्ट्रीम प्रोफ़ाइलों की संख्या और टाइप, प्लेबैक और कैप्चर के लिए इस्तेमाल किए जा सकने वाले डिवाइसों, और ऑडियो एट्रिब्यूट तय किए जा सकते हैं. इसके अलावा, एक्सएमएल फ़ॉर्मैट में नीचे दिए गए बदलाव भी मिलते हैं:
Android 10 में, एक से ज़्यादा ऐप्लिकेशन से एक साथ रिकॉर्डिंग की जा सकती है.
एक साथ कई गतिविधियां होने की वजह से, रिकॉर्डिंग शुरू करने का अनुरोध कभी अस्वीकार नहीं किया जाता.
registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)
कॉलबैक, क्लाइंट को कैप्चर पाथ में बदलाव की सूचना देता है.
इन स्थितियों में, क्लाइंट को साइलेंट ऑडियो सैंपल मिलते हैं:
निजता से जुड़ा कोई इस्तेमाल का उदाहरण (उदाहरण के लिए, VOICE_COMMUNICATION) चालू है.
क्लाइंट में फ़ोरग्राउंड सेवा या फ़ोरग्राउंड यूज़र इंटरफ़ेस (यूआई) नहीं है.
नीति में खास भूमिकाओं की पहचान की गई है:
सुलभता सेवा: निजता से जुड़ा कोई भी इस्तेमाल का उदाहरण चालू होने पर भी रिकॉर्ड कर सकती है.
Assistant: अगर यूज़र इंटरफ़ेस (यूआई) सबसे ऊपर है, तो इसे निजता के लिहाज़ से संवेदनशील माना जाता है.
ऑडियो प्रोफ़ाइलों का स्ट्रक्चर, एचडीएमआई में दिए गए सामान्य ऑडियो डिस्क्रिप्टर से मिलता-जुलता होता है. इससे हर ऑडियो फ़ॉर्मैट के लिए, सैंपलिंग रेट/चैनल मास्क का अलग सेट चालू हो जाता है.
डिवाइसों और स्ट्रीम के बीच सभी संभावित कनेक्शन के लिए, साफ़ तौर पर परिभाषाएं दी गई हैं.
पहले, एक ही एचएएल मॉड्यूल से जुड़े सभी डिवाइसों को कनेक्ट करने की सुविधा, एक गुप्त नियम के तहत मिलती थी. इससे ऑडियो नीति, ऑडियो पैच एपीआई के साथ किए गए कनेक्शन को कंट्रोल नहीं कर पाती थी. एक्सएमएल फ़ॉर्मैट में, टोपोलॉजी की जानकारी से कनेक्शन की सीमाओं के बारे में पता चलता है.
includes फ़ंक्शन की मदद से, स्टैंडर्ड A2DP, USB या सबमिट की गई परिभाषाओं को फिर से सबमिट करने से बचा जा सकता है.
वॉल्यूम कर्व को पसंद के मुताबिक बनाया जा सकता है. पहले, वॉल्यूम टेबल को हार्डकोड किया जाता था. एक्सएमएल फ़ॉर्मैट में, वॉल्यूम टेबल के बारे में बताया गया है और इन्हें पसंद के मुताबिक बनाया जा सकता है.
frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml पर मौजूद टेंप्लेट में, इनमें से कई सुविधाओं का इस्तेमाल किया गया है.
फ़ाइल फ़ॉर्मैट और जगह
ऑडियो नीति की नई कॉन्फ़िगरेशन फ़ाइल,
audio_policy_configuration.xml है और यह
/system/etc में मौजूद है. यहां दिए गए उदाहरणों में, Android 12 और इससे पहले के वर्शन के लिए, ऑडियो नीति का एक आसान कॉन्फ़िगरेशन दिखाया गया है. यह कॉन्फ़िगरेशन, एक्सएमएल फ़ाइल फ़ॉर्मैट में है.
टॉप-लेवल स्ट्रक्चर में ऐसे मॉड्यूल होते हैं जो हर ऑडियो एचएएल हार्डवेयर मॉड्यूल से जुड़े होते हैं. हर मॉड्यूल में मिक्स पोर्ट, डिवाइस पोर्ट, और रूट की सूची होती है:
मिक्स पोर्ट, स्ट्रीम के लिए संभावित कॉन्फ़िगरेशन प्रोफ़ाइलों के बारे में बताते हैं. इन्हें ऑडियो एचएएल में, प्लेबैक और कैप्चर करने के लिए खोला जा सकता है.
डिवाइस पोर्ट, उन डिवाइसों के बारे में बताते हैं जिन्हें अपने टाइप के साथ अटैच किया जा सकता है. साथ ही, अगर ज़रूरी हो, तो पते और ऑडियो प्रॉपर्टी का भी इस्तेमाल किया जा सकता है.
रूट को मिक्स पोर्ट डिस्क्रिप्टर से अलग किया गया है. इससे, डिवाइस से डिवाइस या स्ट्रीम से डिवाइस के रूट की जानकारी देने की सुविधा मिलती है.
वॉल्यूम टेबल, यूज़र इंटरफ़ेस (यूआई) इंडेक्स से वॉल्यूम में अनुवाद करने के लिए इस्तेमाल किए जाने वाले कर्व को परिभाषित करने वाले पॉइंट की आसान सूचियां हैं. एक अलग शामिल की गई फ़ाइल, डिफ़ॉल्ट कर्व उपलब्ध कराती है. हालांकि, किसी इस्तेमाल के उदाहरण और डिवाइस कैटगरी के लिए हर कर्व को बदला जा सकता है.
एक्सएमएल शामिल करने (XInclude) तरीके का इस्तेमाल, अन्य एक्सएमएल फ़ाइलों में मौजूद ऑडियो नीति के कॉन्फ़िगरेशन की जानकारी को शामिल करने के लिए किया जा सकता है. शामिल की गई सभी फ़ाइलों का स्ट्रक्चर, ऊपर बताए गए स्ट्रक्चर के मुताबिक होना चाहिए. साथ ही, इनमें ये पाबंदियां भी लागू होनी चाहिए:
फ़ाइलों में सिर्फ़ टॉप-लेवल एलिमेंट हो सकते हैं.
फ़ाइलों में XInclude एलिमेंट नहीं हो सकते.
इसका इस्तेमाल, स्टैंडर्ड Android ओपन सोर्स प्रोजेक्ट (एओएसपी)
ऑडियो एचएएल मॉड्यूल कॉन्फ़िगरेशन की जानकारी को सभी ऑडियो नीति कॉन्फ़िगरेशन फ़ाइलों (जिसमें गड़बड़ियों की संभावना होती है) में कॉपी करने से रोकने के लिए किया जाता है. यहां दिए गए ऑडियो एचएएल के लिए, ऑडियो नीति कॉन्फ़िगरेशन की स्टैंडर्ड एक्सएमएल फ़ाइल दी गई है:
A2DP:a2dp_audio_policy_configuration.xml
सबमिक्स को फिर से रूट करें:rsubmix_audio_policy_configuration.xml
यूएसबी:usb_audio_policy_configuration.xml
ऑडियो नीति कोड का संगठन
AudioPolicyManager.cpp को कई मॉड्यूल में बांटा गया है, ताकि इसे मैनेज और कॉन्फ़िगर करना आसान हो. frameworks/av/services/audiopolicy के संगठन में नीचे दिए गए मॉड्यूल शामिल हैं.
मॉड्यूल
ब्यौरा
/managerdefault
इसमें सामान्य इंटरफ़ेस और लागू करने की प्रोसेस शामिल है. यह सभी ऐप्लिकेशन पर लागू होती है. AudioPolicyManager.cpp की तरह ही, इसमें इंजन की सुविधाएं और सामान्य कॉन्सेप्ट शामिल नहीं हैं.
/common
बुनियादी क्लास तय करता है. उदाहरण के लिए, इनपुट आउटपुट ऑडियो स्ट्रीम प्रोफ़ाइलों, ऑडियो डिवाइस डिस्क्रिप्टर, ऑडियो पैच, और ऑडियो पोर्ट के लिए डेटा स्ट्रक्चर. इसे पहले AudioPolicyManager.cpp में तय किया गया था.
/engine
ऐसे नियम लागू करता है जिनसे यह तय होता है कि किसी खास इस्तेमाल के उदाहरण के लिए, किस डिवाइस और वॉल्यूम का इस्तेमाल किया जाना चाहिए. यह सामान्य हिस्से के साथ एक स्टैंडर्ड इंटरफ़ेस लागू करता है. जैसे, किसी दिए गए वीडियो चलाने या कैप्चर करने के उदाहरण के लिए सही डिवाइस पाने के लिए या कनेक्ट किए गए डिवाइसों या बाहरी स्थिति (यानी, जब कॉल के लिए किसी डिवाइस का इस्तेमाल ज़रूरी हो) को सेट करने के लिए, जो रूटिंग के फ़ैसले में बदलाव कर सकता है.
पैरामीटर फ़्रेमवर्क पर आधारित नीति इंजन लागू करना (नीचे देखें).
कॉन्फ़िगरेशन, पैरामीटर फ़्रेमवर्क पर आधारित होता है. साथ ही, यह इस बात पर भी निर्भर करता है कि नीति को एक्सएमएल फ़ाइलों से कहां तय किया गया है.
/enginedefault
Android ऑडियो पॉलिसी मैनेजर के पिछले तरीकों के आधार पर, नीति इंजन को लागू करना. यह डिफ़ॉल्ट तौर पर लागू होता है. इसमें हार्ड कोड किए गए ऐसे नियम शामिल होते हैं जो Nexus और AOSP के लागू होने से जुड़े होते हैं.
/service
इसमें बाकी फ़्रेमवर्क के इंटरफ़ेस के साथ बाइंडर इंटरफ़ेस, थ्रेडिंग, और लॉकिंग लागू करने की सुविधा शामिल है.
पैरामीटर फ़्रेमवर्क का इस्तेमाल करके कॉन्फ़िगरेशन
ऑडियो नीति कोड को इस तरह से व्यवस्थित किया गया है कि उसे समझना और मैनेज करना आसान हो. साथ ही, यह पूरी तरह से कॉन्फ़िगरेशन फ़ाइलों से तय की गई ऑडियो नीति के साथ काम करता है. संगठन और ऑडियो नीति का डिज़ाइन, Intel के पैरामीटर फ़्रेमवर्क पर आधारित है. यह पैरामीटर को मैनेज करने के लिए, प्लग इन और नियम पर आधारित फ़्रेमवर्क है.
कॉन्फ़िगर की जा सकने वाली ऑडियो नीति का इस्तेमाल करने पर, वेंडर OEM को ये काम करने में मदद करते हैं:
एक्सएमएल में किसी सिस्टम के स्ट्रक्चर और उसके पैरामीटर के बारे में बताएं.
बताए गए पैरामीटर को ऐक्सेस करने के लिए, C++ में लिखें या बैकएंड (प्लग इन) का फिर से इस्तेमाल करें.
उन शर्तों/नियम को परिभाषित करें (एक्सएमएल में या डोमेन की किसी खास भाषा में) जिनके आधार पर,
दिए गए पैरामीटर को कोई वैल्यू मिलनी चाहिए.
एओएसपी में एक ऑडियो नीति कॉन्फ़िगरेशन फ़ाइल का उदाहरण शामिल होता है, जो Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml में पैरामीटर
फ़्रेमवर्क का इस्तेमाल करता है. ज़्यादा जानकारी के लिए, पैरामीटर फ़्रेमवर्क के बारे में Intel का दस्तावेज़ देखें.
Android 10 या इससे पहले के वर्शन में, कॉन्फ़िगर की जा सकने वाली ऑडियो नीति को बिल्ड के विकल्प USE_CONFIGURABLE_AUDIO_POLICY का इस्तेमाल करके चुना जाता है.
Android 11 या इसके बाद वाले वर्शन में, ऑडियो नीति इंजन का वर्शन audio_policy_configuration.xml फ़ाइल में चुना जाता है.
कॉन्फ़िगर किए जा सकने वाले ऑडियो नीति इंजन को चुनने के लिए, globalConfiguration एलिमेंट के engine_library एट्रिब्यूट की वैल्यू को configurable पर सेट करें. उदाहरण के लिए:
Android 6.0 में, सार्वजनिक एलिमेंट और सिलेक्शन एपीआई को शामिल किया गया है. यह एपीआई, ऑडियो पैच/ऑडियो पोर्ट इन्फ़्रास्ट्रक्चर के ऊपर काम करता है. साथ ही, ऐप्लिकेशन डेवलपर को कनेक्ट किए गए ऑडियो रिकॉर्ड या ट्रैक के लिए, किसी डिवाइस के आउटपुट या इनपुट की प्राथमिकता तय करने की सुविधा देता है.
Android 7.0 में, Enumeration और Selection API की पुष्टि सीटीएस टेस्ट से की जाती है. साथ ही, इसे नेटिव C/C++ (OpenSL ES) ऑडियो स्ट्रीम के लिए रूटिंग को शामिल करने के लिए एक्सटेंड किया गया है.
नेटिव स्ट्रीम की रूटिंग Java में अब भी जारी है. इसमें AudioRouting इंटरफ़ेस भी जोड़ा गया है जो खास तौर पर AudioTrack और AudioRecord क्लास के लिए बताए गए रूटिंग के तरीकों की जगह ले लेता है, एक साथ मिला देता है, और उनका इस्तेमाल बंद कर देता है.
एलिमेंट और सिलेक्शन एपीआई के बारे में ज़्यादा जानने के लिए, Android कॉन्फ़िगरेशन इंटरफ़ेस और OpenSLES_AndroidConfiguration.h देखें.
ऑडियो रूटिंग के बारे में ज़्यादा जानने के लिए, AudioRouting देखें.
एक से ज़्यादा चैनलों पर सहायता
अगर आपका हार्डवेयर और ड्राइवर, एचडीएमआई के ज़रिए मल्टीचैनल ऑडियो के साथ काम करता है, तो ऑडियो स्ट्रीम को सीधे ऑडियो हार्डवेयर पर आउटपुट किया जा सकता है. इससे, ऑडियो फ़्लिंगर मिक्सर को बायपास किया जाता है, ताकि इसे दो चैनलों में डाउनमिक्स न किया जाए. ऑडियो एचएएल को यह बताना होगा कि किसी आउटपुट स्ट्रीम प्रोफ़ाइल में मल्टीचैनल ऑडियो की सुविधाएं काम करती हैं या नहीं. अगर एचएएल अपनी क्षमताओं को दिखाता है, तो डिफ़ॉल्ट नीति मैनेजर, एचडीएमआई पर मल्टीचैनल वीडियो चलाने की अनुमति देता है. लागू करने से जुड़ी जानकारी के लिए, device/samsung/tuna/audio/audio_hw.c देखें.
यह बताने के लिए कि आपके प्रॉडक्ट में मल्टीचैनल ऑडियो आउटपुट है, ऑडियो नीति की कॉन्फ़िगरेशन फ़ाइल में बदलाव करें. इससे, आपके प्रॉडक्ट के मल्टीचैनल आउटपुट के बारे में जानकारी मिलती है. frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml के इस उदाहरण में, डाइनैमिक चैनल मास्क दिखाया गया है. इसका मतलब है कि ऑडियो नीति मैनेजर, कनेक्शन के बाद एचडीएमआई सिंक के साथ काम करने वाले चैनल मास्क के बारे में क्वेरी करता है.
आपके पास स्टैटिक चैनल मास्क तय करने का विकल्प भी होता है, जैसे कि
AUDIO_CHANNEL_OUT_5POINT1. जो ऑडियो डिवाइस मल्टीचैनल ऑडियो के साथ काम नहीं करता उस पर भेजे जाने पर, AudioFlinger का मिक्सर
कॉन्टेंट को स्टीरियो में अपने-आप बदल देता है.
मीडिया कोडेक
पक्का करें कि आपके प्रॉडक्ट के लिए, हार्डवेयर और ड्राइवर के साथ काम करने वाले ऑडियो कोडेक के बारे में सही तरीके से बताया गया हो. ज़्यादा जानकारी के लिए, फ़्रेमवर्क में कोडेक का पता लगाना देखें.
इस पेज पर मौजूद कॉन्टेंट और कोड सैंपल कॉन्टेंट के लाइसेंस में बताए गए लाइसेंस के हिसाब से हैं. Java और OpenJDK, Oracle और/या इससे जुड़ी हुई कंपनियों के ट्रेडमार्क या रजिस्टर किए हुए ट्रेडमार्क हैं.
आखिरी बार 2024-11-08 (UTC) को अपडेट किया गया.
[null,null,["आखिरी बार 2024-11-08 (UTC) को अपडेट किया गया."],[],[]]