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. अब OpenSL ES का इस्तेमाल करके, PCM बफ़र क्यू डेटा लोकेटर की मदद से ऑडियो प्लेयर बनाएं.

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

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

सुनाई देने वाली ग्लिच से बचने के लिए, बफ़र क्यू कॉलबैक हैंडलर को छोटे और तय समय से पहले, अनुमान लगाया जा सकता है. इसका मतलब है कि म्यूटेक्स, कंडिशन, या 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 को कॉल करते हैं (हार्डवेयर कोडेक ऐब्स्ट्रैक्ट हैं, लेकिन डिवाइस पर निर्भर हैं). पार्सर और कोडेक का गलत इस्तेमाल करने के लिए डिज़ाइन किया गया खराब कॉन्टेंट जोखिमों की आशंका, एक पहले से मालूम अटैक वेक्टर है. हमारा सुझाव है कि आप सिर्फ़ भरोसेमंद सोर्स से ही मीडिया चलाएं हो सकता है कि आप अपने ऐप्लिकेशन के हिस्सों को इस तरह से हिस्सों में बांट दें जैसे कि वह कोड जो आपके ऐप्लिकेशन से मीडिया को हैंडल करता हो गैर-भरोसेमंद सोर्स, बाकी सैंडबॉक्स एनवायरमेंट में चलते हैं. उदाहरण के लिए, आपके पास ये विकल्प हैं किसी अलग प्रोसेस में, गैर-भरोसेमंद सोर्स से मीडिया प्रोसेस करना. हालांकि दोनों प्रक्रियाएं अब भी अलग-अलग होने पर हमला और मुश्किल हो जाता है.