OpenSL ES प्रोग्रामिंग नोट

चेतावनी: OpenSL ES अब इस्तेमाल नहीं किया जा रहा है. डेवलपर को GitHub पर उपलब्ध ओपन सोर्स Oboe लाइब्रेरी का इस्तेमाल करना चाहिए. Omoe एक C++ रैपर है, जो काफ़ी हद तक मिलता-जुलता एपीआई उपलब्ध कराता है Aऑडियो. जब AAudio होता है, तब ओबो, AAudio कॉल करता है उपलब्ध है और Aऑडियो उपलब्ध न होने पर OpenSL ES में वापस चला जाता है.

इस सेक्शन में दिए गए नोट, OpenSL ES 1.0.1 खास जानकारी.

ऑब्जेक्ट और इंटरफ़ेस शुरू करना

OpenSL ES प्रोग्रामिंग मॉडल के दो पहलू ऐसे हैं जिनके बारे में नए डेवलपर शायद न जानते हों. पहला, ऑब्जेक्ट और इंटरफ़ेस के बीच का अंतर और दूसरा, शुरू करने का क्रम.

कम शब्दों में, OpenSL ES ऑब्जेक्ट, Java और C++ जैसी प्रोग्रामिंग भाषाओं में ऑब्जेक्ट के कॉन्सेप्ट से मिलता-जुलता है. हालांकि, OpenSL ES ऑब्जेक्ट सिर्फ़ अपने इंटरफ़ेस के ज़रिए दिखता है. इसमें ये शामिल हैं सभी ऑब्जेक्ट के लिए शुरुआती इंटरफ़ेस, जिसे SLObjectItf कहते हैं. किसी ऑब्जेक्ट के लिए कोई हैंडल नहीं है खुद ही, ऑब्जेक्ट के सिर्फ़ SLObjectItf इंटरफ़ेस के लिए हैंडल होता है.

OpenSL ES ऑब्जेक्ट पहले बनाया जाता है, जो एक SLObjectItf दिखाता है. इसके बाद रिएलाइज़ किया गया. यह पहले ऑब्जेक्ट (जो मेमोरी की कमी या अमान्य पैरामीटर होने के अलावा, अन्य सभी वजहों से पूरा नहीं होना चाहिए) प्रोसेस पूरी की जा रही है. ऐसा हो सकता है कि संसाधनों की कमी की वजह से यह प्रोसेस पूरी न हो पाए. 'लागू करें' चरण में, ज़रूरत पड़ने पर ज़्यादा संसाधनों को तय करने के लिए, लागू करने की प्रक्रिया को एक सही जगह मिलती है.

ऑब्जेक्ट बनाने के लिए एपीआई का हिस्सा होने पर, ऐप्लिकेशन पसंदीदा इंटरफ़ेस का कलेक्शन तय करता है जिसे वह बाद में हासिल कर सकता है. ध्यान दें कि यह कलेक्शन अपने-आप नहीं होता इंटरफ़ेस हासिल करना; यह सिर्फ़ उन्हें हासिल करने के भविष्य की ओर इशारा करता है. इंटरफ़ेस को इस तरह से पहचाना जा सकता है अश्लील या अश्लील हो. अगर किसी इंटरफ़ेस को बाद में हासिल किया जाएगा, तो उसे ऐरे में शामिल करना ज़रूरी है. किसी इंप्लिसिट इंटरफ़ेस को ऑब्जेक्ट द्वारा अरे बनाया जाता है, लेकिन इन्हें यहाँ लिस्ट करने में कोई नुकसान नहीं है. OpenSL ES में एक और तरह का इंटरफ़ेस है, जिसे डाइनैमिक होता है, जिसे ऑब्जेक्ट में बताने की ज़रूरत नहीं होती कलेक्शन बनाएं और उसे जोड़ा जा सकता है ऑब्जेक्ट बनाए जाने के बाद. Android को लागू करने पर, आपको एक सुविधा सुविधा के साथ इससे बचने की कोशिश की जाती है. इसके बारे में यहां बताया गया है ऑब्जेक्ट बनाते समय डाइनैमिक इंटरफ़ेस.

ऑब्जेक्ट के बनने और महसूस होने के बाद, ऐप्लिकेशन को हर एक के लिए इंटरफ़ेस हासिल करना चाहिए सुविधा के लिए ज़रूरी है. शुरुआती SLObjectItf में GetInterface का इस्तेमाल करके.

आखिर में, ऑब्जेक्ट अपने इंटरफ़ेस के ज़रिए इस्तेमाल के लिए उपलब्ध है. हालांकि, ध्यान रखें कि कुछ ऑब्जेक्ट को सेटअप करना होगा. खास तौर पर, यूआरआई डेटा सोर्स वाले ऑडियो प्लेयर को ज़्यादा तैयारी करनी है, ताकि कनेक्शन की गड़बड़ियों का पता लगाया जा सके. ज़्यादा जानकारी के लिए, ज़्यादा जानकारी के लिए, ऑडियो प्लेयर प्रीफ़ेच वाला सेक्शन.

ऑब्जेक्ट पर आपका काम पूरा होने के बाद, आपको इसे साफ़ तौर पर मिटाना चाहिए; देखें नीचे दिया गया डेटा मिटाएं सेक्शन.

ऑडियो प्लेयर प्रीफ़ेच

यूआरआई डेटा सोर्स वाले ऑडियो प्लेयर के लिए, Object::Realize तय करता है संसाधन होते हैं, लेकिन उनके पास नहीं डेटा सोर्स से कनेक्ट करें (तैयार करें) या डेटा को पहले से फ़ेच करना शुरू करें. ऐसा तब होता है, जब प्लेयर की स्थिति SL_PLAYSTATE_PAUSED या SL_PLAYSTATE_PLAYING पर सेट है.

इस क्रम में, कुछ जानकारी देर से मिल सकती है. तय सीमा में खास तौर पर, शुरुआत में Player::GetDuration, SL_TIME_UNKNOWN दिखाता है और MuteSolo::GetChannelCount या तो चैनल की गिनती शून्य के साथ वापस आता है या फिर गड़बड़ी का नतीजा SL_RESULT_PRECONDITIONS_VIOLATED. ये एपीआई, जानकारी मिलने के बाद सही वैल्यू दिखाते हैं.

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

'पहले से लोड करने की स्थिति' इंटरफ़ेस, यह पता लगाने के लिए काम आता है कि पूरी जानकारी कब उपलब्ध होगी या आपका ऐप्लिकेशन समय-समय पर पोल कर सकता है. ध्यान दें कि कुछ जानकारी, जैसे कि स्ट्रीमिंग की अवधि MP3 के बारे में जानकारी कभी नहीं होती.

प्रीफ़ेच स्टेटस इंटरफ़ेस, गड़बड़ियों का पता लगाने में भी मददगार होता है. कॉलबैक रजिस्टर करें और चालू करें कम से कम SL_PREFETCHEVENT_FILLLEVELCHANGE और SL_PREFETCHEVENT_STATUSCHANGE इवेंट. अगर ये दोनों इवेंट एक साथ डिलीवर किए जाते हैं और PrefetchStatus::GetFillLevel, शून्य लेवल रिपोर्ट करता है, और PrefetchStatus::GetPrefetchStatus रिपोर्ट SL_PREFETCHSTATUS_UNDERFLOW, इसके बाद यह डेटा स्रोत में ठीक न की जा सकने वाली गड़बड़ी दिखाता है. इसमें ये चीज़ें शामिल नहीं हैं इससे कनेक्ट करो डेटा सोर्स, क्योंकि लोकल फ़ाइल नाम मौजूद नहीं है या नेटवर्क यूआरआई अमान्य है.

OpenSL ES के अगले वर्शन में हैंडलिंग से जुड़ी गड़बड़ियों को डेटा सोर्स. हालांकि, आने वाले समय में बाइनरी के साथ काम करने के लिए, हम ऐसी गड़बड़ी की शिकायत करने के लिए, मौजूदा तरीके का इस्तेमाल करना जारी रखेंगे जिसे ठीक नहीं किया जा सकता.

सारांश में, हमारा सुझाव है कि कोड क्रम का इस्तेमाल करें:

  1. Engine::CreateAudioPlayer
  2. Object:Realize
  3. SL_IID_PREFETCHSTATUS के लिए Object::GetInterface
  4. PrefetchStatus::SetCallbackEventsMask
  5. PrefetchStatus::SetFillUpdatePeriod
  6. PrefetchStatus::RegisterCallback
  7. SL_IID_PLAY के लिए Object::GetInterface
  8. Play::SetPlayState से SL_PLAYSTATE_PAUSED या SL_PLAYSTATE_PLAYING

ध्यान दें: यहां पर प्रॉडक्ट को तैयार करने और उसे प्रीफ़ेच करने की प्रोसेस होती है; इस दौरान कॉलबैक को समय-समय पर स्थिति अपडेट.

खत्म करें

ऐप्लिकेशन से बाहर निकलते समय, सभी ऑब्जेक्ट को मिटाना न भूलें. ऑब्जेक्ट को बनाने के क्रम के उलट, उन्हें मिटाना चाहिए. ऐसा इसलिए, क्योंकि किसी ऐसे ऑब्जेक्ट को मिटाना सुरक्षित नहीं है जिसमें कोई डिपेंडेंट ऑब्जेक्ट हो. उदाहरण के लिए, इस क्रम में नष्ट करें: ऑडियो प्लेयर और रिकॉर्डर, आउटपुट मिक्स, और फिर आखिर में, इंजन.

OpenSL ES, अपने-आप ग़ैर-ज़रूरी डेटा हटाने या इंटरफ़ेस के रेफ़रंस की गिनती करने की सुविधा के साथ काम नहीं करता. Object::Destroy को कॉल करने के बाद, सभी मौजूदा ऐसे इंटरफ़ेस जो असोसिएटेड ऑब्जेक्ट से निकाले जाने पर, वैल्यू तय नहीं होती है.

Android OpenSL ES को लागू करने के बाद, यह पता नहीं लगाया जा सकता कि इस तरह के इंटरफ़ेस गलत तरीके से इस्तेमाल किए गए हैं या नहीं. ऑब्जेक्ट को नष्ट होने के बाद, ऐसे इंटरफ़ेस का इस्तेमाल जारी रखने से आपका ऐप्लिकेशन अचानक बंद हो जाना या ऐसा व्यवहार करना जिसका अंदाज़ा न लगाया जा सके.

हमारा सुझाव है कि आप मुख्य ऑब्जेक्ट इंटरफ़ेस और जुड़े हुए सभी ऑब्जेक्ट, दोनों को साफ़ तौर पर सेट करें आपके ऑब्जेक्ट को नष्ट करने वाले क्रम के हिस्से के तौर पर NULL पर इंटरफ़ेस करता है, जो अनजाने में होने वाली गड़बड़ी को रोकता है पुराने इंटरफ़ेस के हैंडल का गलत इस्तेमाल.

स्टीरियो पैनिंग

जब किसी मोनो सोर्स की स्टीरियो पैनिंग सुविधा को चालू करने के लिए Volume::EnableStereoPosition का इस्तेमाल किया जाता है, तापमान में कुल 3-dB की कमी आई है साउंड पावर लेवल पर सेट करें. यह इसलिए ज़रूरी है, ताकि साउंड पावर का कुल लेवल एक जैसा बना रहे सोर्स है एक चैनल से दूसरे चैनल में पैन किया जाता है. इसलिए, स्टीरियो पोज़िशनिंग की सुविधा सिर्फ़ तब चालू करें, जब आपको इसकी ज़रूरत हो इसे. ज़्यादा जानकारी के लिए, ऑडियो पैनिंग.

कॉलबैक और थ्रेड

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

कॉलबैक हैंडलर को ऐसे इंटरनल थ्रेड से कॉल किया जाता है जो ऐप्लिकेशन से जुड़े नहीं होते और Android रनटाइम से अटैच नहीं होते. इसलिए, वे JNI का इस्तेमाल नहीं कर सकते. क्योंकि ये इंटरनल थ्रेड बेहद ज़रूरी, तो ओपनएसएल ईएस लागू करने के बाद भी, कॉलबैक हैंडलर को ब्लॉक नहीं करना चाहिए या, ज़रूरत से ज़्यादा काम करना.

अगर आपके कॉलबैक हैंडलर को JNI का इस्तेमाल करने या ऐसे काम को एक्ज़ीक्यूट करने की ज़रूरत है जो कॉलबैक के लिए, हैंडलर को इसके बजाय किसी दूसरे थ्रेड को प्रोसेस करने के लिए इवेंट पोस्ट करना चाहिए. के उदाहरण स्वीकार किए जाने वाले कॉलबैक वर्कलोड में अगले आउटपुट बफ़र को रेंडर करना और उसे सूची में रखना शामिल है (किसी AudioPlayer के लिए), अभी-अभी भरे हुए इनपुट बफ़र को प्रोसेस करता है और अगले खाली बफ़र (AudioRecorder के लिए ) या आसान एपीआई, जैसे कि Get परिवार के ज़्यादातर सदस्य. ज़्यादा जानकारी के लिए, वर्कलोड के बारे में नीचे दिया गया परफ़ॉर्मेंस सेक्शन.

ध्यान दें कि बातचीत सुरक्षित है: एक ऐसा Android ऐप्लिकेशन थ्रेड जिसमें JNI डाला गया है की अनुमति है सीधे OpenSL ES API को कॉल करें. इनमें ब्लॉक करने वाले एपीआई भी शामिल हैं. हालांकि, ब्लॉक किए गए कॉल मुख्य थ्रेड से सुझाया गया है, क्योंकि इससे इनका इस्तेमाल किया जा सकता है ऐप्लिकेशन नॉट रिस्पॉन्डिंग (ANR).

कॉलबैक हैंडलर को कॉल करने वाले थ्रेड से जुड़ा फ़ैसला मुख्य रूप से लागू करना. इसकी वजह यह है कि आने वाले समय में ऑप्टिमाइज़ेशन, खास तौर पर, मल्टी-कोर डिवाइस

इस बात की कोई गारंटी नहीं है कि जिस थ्रेड पर कॉलबैक हैंडलर चलता है उसमें अलग-अलग कॉल के लिए एक ही आइडेंटिटी हो. इसलिए, इस रकम से मिले pthread_t पर भरोसा न करें pthread_self() या pid_t को gettid() की ओर से लौटाया गया एक जैसा रहेगा. इसी वजह से, थ्रेड के लोकल स्टोरेज (TLS) एपीआई का इस्तेमाल न करें, जैसे कि pthread_setspecific() और pthread_getspecific(), कॉलबैक से.

लागू करने से यह गारंटी मिलती है कि समान ऑब्जेक्ट, करता है नहीं होता है. हालांकि, एक ही ऑब्जेक्ट के लिए, अलग-अलग तरह के एक साथ कॉलबैक की सुविधा का इस्तेमाल किया जा सकता है अलग-अलग थ्रेड हैं.

परफ़ॉर्मेंस

OpenSL ES एक नेटिव C API है, इसलिए OpenSL ES को कॉल करने वाले नॉन-रनटाइम ऐप्लिकेशन थ्रेड में कोई रनटाइम से जुड़े ओवरहेड, जैसे कि कूड़ा इकट्ठा करने की प्रोसेस रोकना. OpenSL ES का इस्तेमाल करने पर, परफ़ॉर्मेंस में कोई और फ़ायदा नहीं मिलता. हालांकि, एक अपवाद है, जिसके बारे में नीचे बताया गया है. खास तौर पर, OpenSL ES का इस्तेमाल करने पर, कॉन्टेंट को बेहतर बनाने की गारंटी नहीं मिलती है. जैसे, ऑडियो में इंतज़ार का समय कम या ज़्यादा होना प्लैटफ़ॉर्म पर आम तौर पर जो सेवाएं दी जाती हैं उनके आधार पर शेड्यूल तय करना. दूसरी ओर, जहां Android प्लैटफ़ॉर्म और उसे लागू करने के लिए खास डिवाइसों को बेहतर बनाया जा रहा है. यह एक OpenSL ES ऐप्लिकेशन है आने वाले समय में, सिस्टम की परफ़ॉर्मेंस में सुधार होगा.

ऐसा ही एक विकास है, ऑडियो आउटपुट में इंतज़ार का समय. कम दर वाले मॉडल के लिए आधार आउटपुट इंतज़ार के समय को पहले Android 4.1 (एपीआई लेवल 16) में शामिल किया गया था. इसके बाद, Android 4.2 (एपीआई लेवल 17) में यह प्रोसेस जारी है. ये सुधार इनके ज़रिए उपलब्ध हैं: उन डिवाइस को लागू करने के लिए OpenSL ES जो दावा सुविधा android.hardware.audio.low_latency. अगर डिवाइस इस सुविधा पर दावा नहीं करता, लेकिन Android 2.3 (एपीआई लेवल 9) पर काम करता है तो आप OpenSL ES API का इस्तेमाल कर सकते हैं, लेकिन आउटपुट इंतज़ार का समय ज़्यादा हो सकता है. कम आउटपुट इंतज़ार के समय का पाथ सिर्फ़ तब इस्तेमाल किया जाता है, जब ऐप्लिकेशन बफ़र साइज़ और सैंपल रेट का अनुरोध करता है जो हैं डिवाइस के मूल आउटपुट कॉन्फ़िगरेशन के साथ काम करता है. ये पैरामीटर खास तौर पर किसी डिवाइस के लिए और नीचे दी गई जानकारी के हिसाब से, साफ़ तौर पर सबमिट किए जाने चाहिए.

Android 4.2 (एपीआई लेवल 17) से शुरू करते हुए, कोई ऐप्लिकेशन डिवाइस के प्राइमरी आउटपुट के लिए, प्लैटफ़ॉर्म नेटिव या सबसे बेहतर आउटपुट सैंपल रेट और बफ़र साइज़ स्ट्रीम. अगर किसी ऐप्लिकेशन को अभी बताए गए सुविधा टेस्ट के साथ इस्तेमाल किया जाता है, तो वह अब खुद को कॉन्फ़िगर कर सकता है यह सुविधा, सहायता का दावा करने वाले डिवाइसों पर इंतज़ार के समय को कम करने के लिए सही तरीके से काम करती है.

Android 4.2 (एपीआई लेवल 17) और इससे पहले के वर्शन के लिए, बफ़र की संख्या दो या इससे ज़्यादा होती है इंतज़ार का समय कम होने पर यह ज़रूरी है. Android 4.3 (एपीआई लेवल 18) से, इंतज़ार का समय कम करने के लिए, एक बफ़र की संख्या काफ़ी है.

आउटपुट इफ़ेक्ट के लिए, सभी OpenSL ES इंटरफ़ेस, कम इंतज़ार के समय वाले पाथ को रोकते हैं.

सुझाया गया क्रम यह है:

  1. OpenSL ES के इस्तेमाल की पुष्टि करने के लिए, एपीआई लेवल 9 या उससे बाद के लेवल की जांच करें.
  2. इस तरह के कोड का इस्तेमाल करके, android.hardware.audio.low_latency सुविधा की जांच करें:

    Kotlin

    import android.content.pm.PackageManager
...
val pm: PackageManager = context.packageManager
val claimsFeature: Boolean = pm.hasSystemFeature(PackageManager.FEATURE_AUDIO_LOW_LATENCY)

    Java

    import android.content.pm.PackageManager;
...
PackageManager pm = getContext().getPackageManager();
boolean claimsFeature = pm.hasSystemFeature(PackageManager.FEATURE_AUDIO_LOW_LATENCY);
  3. यूआरएल के इस्तेमाल की पुष्टि करने के लिए, एपीआई लेवल 17 या उसके बाद के लेवल की जांच करें android.media.AudioManager.getProperty().
  4. इस डिवाइस के लिए, नेटिव या सबसे बेहतर आउटपुट सैंपल रेट और बफ़र साइज़ पाएं प्राइमरी आउटपुट इस तरह के कोड का इस्तेमाल करके स्ट्रीम करें:

    Kotlin

    import android.media.AudioManager
...
val am = getSystemService(Context.AUDIO_SERVICE) as AudioManager
val sampleRate: String = am.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE)
val framesPerBuffer: String = am.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER)

    Java

    import android.media.AudioManager;
...
AudioManager am = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
String sampleRate = am.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE);
String framesPerBuffer = am.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER);
    ध्यान दें कि sampleRate और framesPerBuffer स्ट्रिंग हैं. पहली जांच शून्य और फिर Integer.parseInt() का इस्तेमाल करके पूर्णांक में बदलें.
  5. अब PCM बफ़र कतार डेटा लोकेटर के साथ AudioPlayer बनाने के लिए, OpenSL ES का इस्तेमाल करें.

ध्यान दें: Google आपके यूआरएल पैरामीटर को कैसे इस्तेमाल करेगा, यह तय करने के लिए ऑडियो बफ़र का साइज़ यह ऐप्लिकेशन OpenSL ES ऑडियो का मूल बफ़र साइज़ और सैंपल रेट तय करता है आपके ऑडियो डिवाइस पर मौजूद ऐप्लिकेशन. audio-buffer-size सैंपल देखने के लिए, GitHub पर भी जाया जा सकता है.

इंतज़ार का समय कम करने वाले ऑडियो प्लेयर की संख्या सीमित है. अगर आपके ऐप्लिकेशन में कुछ से ज़्यादा ऑडियो सोर्स की ज़रूरत है, तो ऐप्लिकेशन लेवल पर ऑडियो को मिक्स करें. पक्का करें कि आपने ऑडियो को मिटाया न हो प्लेयर, जब आपकी गतिविधि को रोका जाता है, तब ये ऐप्लिकेशन दुनिया भर में उपलब्ध एक संसाधन होते हैं. इन्हें दूसरे ऐप्लिकेशन के साथ शेयर किया जाता है.

सुनाई देने वाली ग्लिच से बचने के लिए, बफ़र क्यू कॉलबैक हैंडलर को छोटे और तय समय से पहले, अनुमान लगाया जा सकता है. आम तौर पर, इसका मतलब है कि म्यूटेक्स, शर्तों या I/O ऑपरेशन पर अनलिमिटेड ब्लॉकिंग नहीं है. इसके बजाय, टाइम आउट के साथ लॉक, और इंतज़ार का समय आज़माएं. ब्लॉक न करने वाले एल्गोरिदम चुनें.

अगला बफ़र बनाने के लिए ( AudioPlayer के लिए) या पिछले बफ़र का इस्तेमाल करने के लिए कंप्यूटेशन (हिसाब लगाना ज़रूरी है) बफ़र (AudioRecord के लिए) में हर कॉलबैक में करीब उतना ही समय लगना चाहिए. ऐसे एल्गोरिदम से बचें जो तय समय के अंदर काम नहीं करते या जो सिस्टम में बर्स्ट होते हैं कर सकते हैं. अगर किसी दिए गए कॉलबैक में सीपीयू का समय बीता, तो कॉलबैक कंप्यूटेशन बर्स्ट होता है औसत से काफ़ी ज़्यादा है. कुल मिलाकर, यह सबसे सही है कि सीपीयू पर काम करने में लगने वाला समय हैंडलर को शून्य के पास वैरिएंस होना चाहिए और हैंडलर को अनबाउंड समय के लिए ब्लॉक नहीं करना चाहिए.

इंतज़ार का समय कम करने वाला ऑडियो सिर्फ़ इन आउटपुट के लिए इस्तेमाल किया जा सकता है:

कुछ डिवाइसों पर, स्पीकर के इंतज़ार का समय अन्य पाथ की तुलना में ज़्यादा होता है. ऐसा स्पीकर में सुधार करने की सुविधा और सुरक्षा.

Android 5.0 (एपीआई लेवल 21) के मुताबिक, कम इंतज़ार का समय ऑडियो इनपुट चुनिंदा डिवाइस पर समर्थित है. इस सुविधा का फ़ायदा पाने के लिए, पहले पुष्टि करें इंतज़ार का समय कम करने वाला आउटपुट ऊपर बताए गए तरीके से उपलब्ध है. इंतज़ार का समय कम करने की सुविधा कम इंतज़ार का समय इनपुट सुविधा के लिए एक ज़रूरी शर्त है. इसके बाद, सैंपल रेट और बफ़र साइज़ का इस्तेमाल आउटपुट के लिए किया जाएगा. इनपुट इफ़ेक्ट के लिए OpenSL ES इंटरफ़ेस इंतज़ार का समय कम होने से रोकें. रिकॉर्ड प्रीसेट इंतज़ार का समय कम करने के लिए, SL_ANDROID_RECORDING_PRESET_VOICE_RECOGNITION का इस्तेमाल करना चाहिए; यह प्रीसेट, डिवाइस के हिसाब से डिजिटल सिग्नल प्रोसेसिंग को बंद कर देता है. इससे इनपुट पाथ में देरी हो सकती है. रिकॉर्ड प्रीसेट के बारे में ज़्यादा जानकारी के लिए, देखें Android कॉन्फ़िगरेशन इंटरफ़ेस सेक्शन में जोड़ा जा सकता है.

एक साथ इनपुट और आउटपुट के लिए, हर साइड के लिए अलग-अलग बफ़र कतार के पूरा होने के हैंडलर का इस्तेमाल किया जाता है. इन कॉलबैक के रिलेटिव ऑर्डर या इसके सिंक होने की कोई गारंटी नहीं है ऑडियो घड़ियां, भले ही दोनों साइड में एक जैसा सैंपल रेट इस्तेमाल किया गया हो. आपका आवेदन को बफ़र करना चाहिए सही बफ़र सिंक होने वाला डेटा.

संभावित तौर पर स्वतंत्र ऑडियो घड़ियों का एक नतीजा है कि एसिंक्रोनस सैंपल रेट की ज़रूरत होती है कन्वर्ज़न होता है. एसिंक्रोनस सैंपल रेट के लिए एक आसान तकनीक (हालांकि ऑडियो क्वालिटी के लिए यह सही नहीं है) इसका मतलब है कि किसी शून्य-क्रॉसिंग पॉइंट के पास ज़रूरत के मुताबिक सैंपल कॉपी करना या उन्हें छोड़ना. ज़्यादा बेहतर कन्वर्ज़न मिल सकते हैं.

परफ़ॉर्मेंस के मोड

OpenSL ES ने Android 7.1 (एपीआई लेवल 25) के साथ शुरुआत करते हुए, परफ़ॉर्मेंस मोड तय करने का एक तरीका पेश किया है ऑडियो पाथ के लिए. इसके विकल्प:

  • SL_ANDROID_PERFORMANCE_NONE: परफ़ॉर्मेंस से जुड़ी कोई खास शर्त नहीं है. हार्डवेयर और सॉफ़्टवेयर इफ़ेक्ट इस्तेमाल करने की अनुमति दें.
  • SL_ANDROID_PERFORMANCE_LATENCY: इंतज़ार के समय को प्राथमिकता दी जाती है. कोई हार्डवेयर नहीं या सॉफ़्टवेयर इफ़ेक्ट. यह डिफ़ॉल्ट मोड है.
  • SL_ANDROID_PERFORMANCE_LATENCY_EFFECTS: इंतज़ार के समय को प्राथमिकता दी जाती है हार्डवेयर और सॉफ़्टवेयर इफ़ेक्ट को भी मंज़ूरी मिलेगी.
  • SL_ANDROID_PERFORMANCE_POWER_SAVING: ताकत बचाने को प्राथमिकता दी गई. हार्डवेयर और सॉफ़्टवेयर इफ़ेक्ट इस्तेमाल करने की अनुमति दें.

ध्यान दें: अगर आपको इंतज़ार का समय कम नहीं रखना है और आपको इनमें डिवाइस में पहले से मौजूद ऑडियो इफ़ेक्ट का फ़ायदा लिया जा सकता है. उदाहरण के लिए, अकूस्टिक परफ़ॉर्मेंस को बेहतर बनाने के लिए वीडियो प्लेबैक के लिए गुणवत्ता), आपको स्पष्ट रूप से प्रदर्शन मोड SL_ANDROID_PERFORMANCE_NONE.

परफ़ॉर्मेंस मोड सेट करने के लिए, आपको Android का इस्तेमाल करके SetConfiguration को कॉल करना होगा कॉन्फ़िगरेशन इंटरफ़ेस, जैसा कि नीचे दिखाया गया है: 

  // Obtain the Android configuration interface using a previously configured SLObjectItf.
  SLAndroidConfigurationItf configItf = nullptr;
  (*objItf)->GetInterface(objItf, SL_IID_ANDROIDCONFIGURATION, &configItf);

  // Set the performance mode.
  SLuint32 performanceMode = SL_ANDROID_PERFORMANCE_NONE;
    result = (*configItf)->SetConfiguration(configItf, SL_ANDROID_KEY_PERFORMANCE_MODE,
                                                     &performanceMode, sizeof(performanceMode));

सुरक्षा और अनुमतियां

Android में सुरक्षा की सुविधा, प्रोसेस लेवल पर उपलब्ध होती है. इससे यह तय किया जाता है कि कौनसा ऐप्लिकेशन क्या कर सकता है. Java प्रोग्रामिंग भाषा कोड, नेटिव कोड के अलावा कुछ नहीं कर सकता और न ही नेटिव कोड इनसे ज़्यादा कुछ कर सकता है Java प्रोग्रामिंग भाषा कोड. इनमें सिर्फ़ उपलब्ध एपीआई का अंतर है.

OpenSL ES का इस्तेमाल करने वाले ऐप्लिकेशन को, इसी तरह की अनुमतियों के लिए उन अनुमतियों का अनुरोध करना होगा नॉन-नेटिव एपीआई. उदाहरण के लिए, अगर आपका ऐप्लिकेशन ऑडियो रिकॉर्ड करता है, तो उसे android.permission.RECORD_AUDIO की अनुमति. ऑडियो इफ़ेक्ट का इस्तेमाल करने वाले ऐप्लिकेशन को इनकी ज़रूरत होती है android.permission.MODIFY_AUDIO_SETTINGS. नेटवर्क यूआरआई संसाधन चलाने वाले ऐप्लिकेशन android.permission.NETWORK चाहिए. ज़्यादा जानकारी के लिए, सिस्टम अनुमतियों के साथ काम करना लेख पढ़ें.

प्लैटफ़ॉर्म के वर्शन और लागू करने के तरीके के आधार पर, मीडिया कॉन्टेंट पार्स करने वाले टूल और सॉफ़्टवेयर कोडेक, OpenSL ES को कॉल करने वाले Android ऐप्लिकेशन के कॉन्टेक्स्ट में चल सकते हैं. हार्डवेयर कोडेक, डिवाइस पर निर्भर होते हैं. पार्सर और कोडेक का गलत इस्तेमाल करने के लिए डिज़ाइन किया गया खराब कॉन्टेंट जोखिमों की आशंका, एक पहले से मालूम अटैक वेक्टर है. हमारा सुझाव है कि आप सिर्फ़ भरोसेमंद सोर्स से ही मीडिया चलाएं हो सकता है कि आप अपने ऐप्लिकेशन के अलग-अलग हिस्सों को इस तरह से बांटें कि वह कोड एक ऐसे कोड से मीडिया को मैनेज करता है गैर-भरोसेमंद सोर्स, बाकी सैंडबॉक्स एनवायरमेंट में चलते हैं. उदाहरण के लिए, आपके पास ये विकल्प हैं किसी अलग प्रोसेस में, गैर-भरोसेमंद सोर्स से मीडिया प्रोसेस करना. हालांकि दोनों प्रक्रियाएं अब भी अलग-अलग होने पर हमला और मुश्किल हो जाता है.