Android के लिए OpenSL ES

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

इस पेज पर बताया गया है कि OpenSL ES™ को NDK में लागू करने का तरीका, OpenSL ES 1.0.1 के रेफ़रंस स्पेसिफ़िकेशन से किस तरह अलग है. अगर खास तौर पर दिए गए सैंपल कोड का इस्तेमाल किया जाता है, तो हो सकता है कि आपको इसमें बदलाव करना पड़े, ताकि यह Android पर काम कर सके.

जब तक अलग से न बताया जाए, तब तक सभी सुविधाएं Android 2.3 (एपीआई लेवल 9) और उसके बाद के वर्शन पर उपलब्ध हैं. कुछ सुविधाएं सिर्फ़ Android 4.0 (एपीआई लेवल 14) के लिए उपलब्ध हैं. इन सुविधाओं के आगे यह जानकारी दी गई है.

ध्यान दें: Android Compatibility Definition Document (CDD) में, Android के साथ काम करने वाले डिवाइस के लिए ज़रूरी हार्डवेयर और सॉफ़्टवेयर की जानकारी दी गई है. कंपैटबिलिटी प्रोग्राम के बारे में ज़्यादा जानकारी के लिए, Android पर काम करने की सुविधा देखें. साथ ही, CDD के असल दस्तावेज़ के लिए, CDD देखें.

OpenSL ES, C प्रोग्रामिंग भाषा का इंटरफ़ेस उपलब्ध कराता है. इसे C++ का इस्तेमाल करके भी ऐक्सेस किया जा सकता है. यह इन Android Java API के ऑडियो सेक्शन जैसी सुविधाएं देता है:

Android के सभी नेटिव डेवलपमेंट किट (NDK) की तरह ही, Android के लिए OpenSL ES का मुख्य मकसद, शेयर की गई लाइब्रेरी को लागू करना है, ताकि उन्हें Java नेटिव इंटरफ़ेस (JNI ) का इस्तेमाल करके कॉल किया जा सके. NDK का मकसद, सिर्फ़ C/C++ ऐप्लिकेशन लिखना नहीं है. हालांकि, OpenSL ES एक सभी सुविधाओं वाला एपीआई है. हम उम्मीद करते हैं कि आप सिर्फ़ इस एपीआई का इस्तेमाल करके, ऑडियो से जुड़ी अपनी ज़्यादातर ज़रूरतों को पूरा कर सकते हैं. इसके लिए, आपको Android रनटाइम में कोड चलाने की ज़रूरत नहीं होगी.

ध्यान दें: Android नेटिव ऑडियो (बेहतर परफ़ॉर्मेंस वाला ऑडियो) एपीआई, OpenSL ES पर आधारित है. हालांकि, यह किसी भी OpenSL ES 1.0.1 प्रोफ़ाइल (गेम, संगीत या फ़ोन) के मुताबिक काम नहीं करता. ऐसा इसलिए होता है, क्योंकि Android किसी भी एक प्रोफ़ाइल के लिए ज़रूरी सभी सुविधाएं लागू नहीं करता. Android एक्सटेंशन पेज पर, ऐसे सभी मामलों के बारे में बताया गया है जिनमें Android, स्पेसिफ़िकेशन के मुताबिक काम नहीं करता.

रेफ़रंस स्पेसिफ़िकेशन से इनहेरिट की गई सुविधाएं

OpenSL ES के Android NDK वर्शन में, रेफ़रंस स्पेसिफ़िकेशन की ज़्यादातर सुविधाएं शामिल हैं. हालांकि, इनमें कुछ सीमाएं भी हैं.

ग्लोबल एंट्री पॉइंट

Android के लिए OpenSL ES, Android स्पेसिफ़िकेशन में मौजूद सभी ग्लोबल एंट्री पॉइंट के साथ काम करता है. इन एंट्री पॉइंट में ये शामिल हैं:

  • slCreateEngine
  • slQueryNumSupportedEngineInterfaces
  • slQuerySupportedEngineInterfaces

ऑब्जेक्ट और इंटरफ़ेस

इस टेबल में उन ऑब्जेक्ट और इंटरफ़ेस के बारे में बताया गया है जिनके साथ OpenSL ES के Android NDK वर्शन का इस्तेमाल किया जा सकता है. अगर सेल में हां दिखता है, तो इसका मतलब है कि यह सुविधा लागू करने के लिए उपलब्ध है.

ऑब्जेक्ट और इंटरफ़ेस के लिए Android NDK की सहायता.

सुविधा ऑडियो प्लेयर ऑडियो रिकॉर्डर इंजन आउटपुट मिक्स
बेस बढ़ाएं हां नहीं नहीं हां
बफ़र सूची हां नहीं नहीं नहीं
बफ़र क्यू डेटा लोकेटर हां: सोर्स नहीं नहीं नहीं
डाइनैमिक इंटरफ़ेस मैनेजमेंट हां हां हां हां
इफ़ेक्ट भेजना हां नहीं नहीं नहीं
इंजन नहीं नहीं हां नहीं
Environmental reverb नहीं नहीं नहीं हां
आवाज़ बराबर करने की सुविधा हां नहीं नहीं हां
I/O डिवाइस डेटा लोकेटर नहीं हां: सोर्स नहीं नहीं
मेटाडेटा निकालना हां: PCM में डिकोड करें नहीं नहीं नहीं
म्यूट सोलो हां नहीं नहीं नहीं
ऑब्जेक्ट हां हां हां हां
आउटपुट मिक्स लोकेटर हां: सिंक करें नहीं नहीं नहीं
चलाएं हां नहीं नहीं नहीं
वीडियो चलाने की स्पीड हां नहीं नहीं नहीं
प्रीफ़ेच की स्थिति हां नहीं नहीं नहीं
प्रीसेट रीवर्ब नहीं नहीं नहीं हां
रिकॉर्ड करें नहीं हां नहीं नहीं
खोजें हां नहीं नहीं नहीं
यूआरआई डेटा लोकेटर हां: सोर्स नहीं नहीं नहीं
वर्चुअलाइज़र हां नहीं नहीं हां
वॉल्यूम हां नहीं नहीं नहीं

अगले सेक्शन में, इनमें से कुछ सुविधाओं की सीमाओं के बारे में बताया गया है.

सीमाएं

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

डाइनैमिक इंटरफ़ेस मैनेजमेंट

Android के लिए OpenSL ES, RemoveInterface या ResumeInterface के साथ काम नहीं करता है.

इफ़ेक्ट के कॉम्बिनेशन: एनवायरमेंट रिवरब और प्रीसेट रिवरब

एक ही आउटपुट मिक्स में, एनवायरमेंटल रिवरब और प्रीसेट रिवरब, दोनों का इस्तेमाल नहीं किया जा सकता.

अगर प्लैटफ़ॉर्म को लगता है कि सीपीयू पर बहुत ज़्यादा लोड पड़ेगा, तो हो सकता है कि वह इफ़ेक्ट के अनुरोधों को अनदेखा कर दे.

इफ़ेक्ट भेजना

SetSendLevel() में हर ऑडियो प्लेयर के लिए, मैसेज भेजने का एक लेवल काम करता है.

Environmental reverb

एनवायरमेंटल रिवरब, SLEnvironmentalReverbSettings स्ट्रक्चर के reflectionsDelay, reflectionsLevel या reverbDelay फ़ील्ड के साथ काम नहीं करता.

MIME डेटा फ़ॉर्मैट

MIME डेटा फ़ॉर्मैट का इस्तेमाल, सिर्फ़ यूआरआई डेटा लोकेटर के साथ और सिर्फ़ ऑडियो प्लेयर के लिए किया जा सकता है. ऑडियो रिकॉर्ड करने के लिए, इस डेटा फ़ॉर्मैट का इस्तेमाल नहीं किया जा सकता.

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

Android के लिए OpenSL ES, इन ऑडियो फ़ॉर्मैट के साथ काम करता है. हालांकि, इसके लिए ज़रूरी है कि Android प्लैटफ़ॉर्म पर भी ये फ़ॉर्मैट काम करते हों:

  • WAV PCM.
  • WAV कानून.
  • WAV ulaw.
  • MP3 Ogg Vorbis.
  • AAC LC.
  • HE-AACv1 (AAC+).
  • HE-AACv2 (बेहतर AAC+).
  • AMR.
  • FLAC.

ध्यान दें: Android पर काम करने वाले ऑडियो फ़ॉर्मैट की सूची के लिए, काम करने वाले मीडिया फ़ॉर्मैट देखें.

OpenSL ES के इस वर्शन में, इन और अन्य फ़ॉर्मैट को मैनेज करने पर ये सीमाएं लागू होती हैं:

  • AAC फ़ॉर्मैट, MP4 या ADTS कंटेनर में होने चाहिए.
  • Android के लिए OpenSL ES, MIDI के साथ काम नहीं करता.
  • WMA, AOSP का हिस्सा नहीं है. साथ ही, हमने इसकी पुष्टि नहीं की है कि यह Android के लिए OpenSL ES के साथ काम करता है या नहीं.
  • Android NDK में OpenSL ES लागू करने पर, डीआरएम या एन्क्रिप्ट (सुरक्षित) किए गए कॉन्टेंट को सीधे तौर पर चलाने की सुविधा काम नहीं करती. सुरक्षित ऑडियो कॉन्टेंट को चलाने के लिए, आपको उसे चलाने से पहले अपने ऐप्लिकेशन में डिक्रिप्ट करना होगा. साथ ही, आपके ऐप्लिकेशन को डीआरएम से जुड़ी पाबंदियां लागू करनी होंगी.

Android के लिए OpenSL ES, ऑब्जेक्ट में बदलाव करने के लिए इन तरीकों का इस्तेमाल नहीं करता:

  • Resume()
  • RegisterCallback()
  • AbortAsyncOperation()
  • SetPriority()
  • GetPriority()
  • SetLossOfControlInterfaces()

PCM डेटा फ़ॉर्मैट

बफ़र कतार के साथ सिर्फ़ PCM डेटा फ़ॉर्मैट का इस्तेमाल किया जा सकता है. काम करने वाले PCM प्लेबैक कॉन्फ़िगरेशन की ये विशेषताएं हैं:

  • 8-बिट साइन नहीं किया गया या 16-बिट साइन किया गया.
  • मोनो या स्टीरियो.
  • लिटिल-एंडियन बाइट ऑर्डरिंग.
  • सैंपल रेट:
    • 8,000 हर्ट्ज़.
    • 11,025 हर्ट्ज़.
    • 12,000 हर्ट्ज़.
    • 16,000 हर्ट्ज़.
    • 22,050 हर्ट्ज़.
    • 24,000 हर्ट्ज़.
    • 32,000 हर्ट्ज़.
    • 44,100 हर्ट्ज़.
    • 48,000 हर्ट्ज़.

Android के लिए OpenSL ES, रिकॉर्डिंग के लिए जो कॉन्फ़िगरेशन इस्तेमाल करता है वे डिवाइस पर निर्भर करते हैं. आम तौर पर, 16,000 हर्ट्ज़ मोनो/16-बिट साइन वाला कॉन्फ़िगरेशन, किसी भी डिवाइस पर उपलब्ध होता है.

samplesPerSec फ़ील्ड की वैल्यू, मिलीहर्ट्ज़ की यूनिट में होती है. भले ही, इसका नाम गुमराह करने वाला हो. गलती से गलत वैल्यू का इस्तेमाल होने से बचने के लिए, हमारा सुझाव है कि आप इस फ़ील्ड को शुरू करने के लिए, SL_SAMPLINGRATE_44_1 जैसी किसी एक सिंबल कॉन्स्टेंट का इस्तेमाल करें.

Android 5.0 (एपीआई लेवल 21) और उसके बाद के वर्शन पर, फ़्लोटिंग-पॉइंट डेटा का इस्तेमाल किया जा सकता है.

वीडियो चलाने की स्पीड

OpenSL ES प्लेबैक रेट से पता चलता है कि कोई ऑब्जेक्ट, डेटा को किस रफ़्तार से दिखाता है. इसे सामान्य स्पीड के हज़ारवें हिस्से या प्रति मील में दिखाया जाता है. उदाहरण के लिए, 1,000 प्रति मिल वीडियो चलाने की दर 1,000/1,000 या सामान्य स्पीड होती है. रेट रेंज एक क्लोज़्ड इंटरवल होता है, जो वीडियो चलाने की संभावित दरों की रेंज दिखाता है.

प्लैटफ़ॉर्म के वर्शन और लागू करने के तरीके के हिसाब से, वीडियो चलाने की दर की सीमाओं और अन्य सुविधाओं के काम करने का तरीका अलग-अलग हो सकता है. आपका ऐप्लिकेशन, डिवाइस से क्वेरी करने के लिए PlaybackRate::GetRateRange() या PlaybackRate::GetCapabilitiesOfRate() का इस्तेमाल करके, रनटाइम के दौरान इन सुविधाओं का पता लगा सकता है.

आम तौर पर, कोई डिवाइस PCM फ़ॉर्मैट में डेटा सोर्स के लिए एक ही रेट रेंज के साथ काम करता है. साथ ही, अन्य फ़ॉर्मैट के लिए यूनिटी रेट की रेंज 1,000 प्रति मिल से 1,000 प्रति मिल होती है. इसका मतलब है कि यूनिटी रेट की रेंज, एक ही वैल्यू होती है.

रिकॉर्ड करें

Android के लिए OpenSL ES, SL_RECORDEVENT_HEADATLIMIT या SL_RECORDEVENT_HEADMOVING इवेंट के साथ काम नहीं करता.

खोजें

SetLoop() तरीके से, पूरी फ़ाइल को लूप किया जा सकता है. लूपिंग की सुविधा चालू करने के लिए, startPos पैरामीटर को 0 पर और endPos पैरामीटर को SL_TIME_UNKNOWN पर सेट करें.

बफ़र सूची का डेटा लोकेटर

बफ़र सूची के लिए डेटा लोकेटर वाला ऑडियो प्लेयर या रिकॉर्डर, सिर्फ़ PCM डेटा फ़ॉर्मैट के साथ काम करता है.

I/O डिवाइस डेटा लोकेटर

Android के लिए OpenSL ES सिर्फ़ तब I/O डिवाइस डेटा लोकेटर के इस्तेमाल के साथ काम करता है, जब आपने Engine::CreateAudioRecorder() के लिए लोकेटर को डेटा सोर्स के तौर पर तय कर दिया हो. नीचे दिए गए कोड स्निपेट में मौजूद वैल्यू का इस्तेमाल करके, डिवाइस डेटा लोकेटर को शुरू करें: 

SLDataLocator_IODevice loc_dev =
  {SL_DATALOCATOR_IODEVICE, SL_IODEVICE_AUDIOINPUT,
  SL_DEFAULTDEVICEID_AUDIOINPUT, NULL};

यूआरआई डेटा लोकेटर

Android के लिए OpenSL ES, सिर्फ़ MIME डेटा फ़ॉर्मैट के साथ यूआरआई डेटा लोकेटर का इस्तेमाल कर सकता है. साथ ही, इसका इस्तेमाल सिर्फ़ ऑडियो प्लेयर के लिए किया जा सकता है. ऑडियो रिकॉर्ड करने वाले टूल के लिए, यूआरआई डेटा लोकेटर का इस्तेमाल नहीं किया जा सकता. यूआरआई में सिर्फ़ http: और file: स्कीम का इस्तेमाल किया जा सकता है. https:, ftp: या content: जैसी अन्य स्कीम इस्तेमाल करने की अनुमति नहीं है.

हमने Android प्लैटफ़ॉर्म पर ऑडियो के साथ rtsp: के लिए सहायता की पुष्टि नहीं की है.

डेटा स्ट्रक्चर

Android, OpenSL ES 1.0.1 डेटा स्ट्रक्चर के साथ काम करता है:

  • SLDataFormat_MIME
  • SLDataFormat_PCM
  • SLDataLocator_BufferQueue
  • SLDataLocator_IODevice
  • SLDataLocator_OutputMix
  • SLDataLocator_URI
  • SLDataSink
  • SLDataSource
  • SLEngineOption
  • SLEnvironmentalReverbSettings
  • SLInterfaceID

प्लैटफ़ॉर्म कॉन्फ़िगरेशन

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

इन इंजन के विकल्पों को पहचाना जाता है, लेकिन slCreateEngine उन्हें अनदेखा कर देता है:

  • SL_ENGINEOPTION_THREADSAFE
  • SL_ENGINEOPTION_LOSSOFCONTROL

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

प्रोग्रामिंग से जुड़े नोट

OpenSL ES प्रोग्रामिंग नोट में OpenSL ES को सही तरीके से लागू करने के लिए अतिरिक्त जानकारी दी गई है.

ध्यान दें: आपकी सुविधा के लिए, हमने docs/opensles/OpenSL_ES_Specification_1.0.1.pdf में NDK के साथ OpenSL ES 1.0.1 स्पेसिफ़िकेशन की कॉपी शामिल की है.

प्लैटफ़ॉर्म से जुड़ी समस्याएं

इस सेक्शन में, इन एपीआई के साथ काम करने वाले प्लैटफ़ॉर्म की शुरुआती रिलीज़ में मौजूद समस्याओं के बारे में बताया गया है.

डाइनैमिक इंटरफ़ेस मैनेजमेंट

DynamicInterfaceManagement::AddInterface काम नहीं करता. इसके बजाय, Create() को पास किए गए ऐरे में इंटरफ़ेस की जानकारी दें, जैसा कि इवोल्यूशनरी रिवरब के उदाहरण के कोड में दिखाया गया है.

OpenSL ES के आने वाले वर्शन के लिए प्लान बनाएं

Android के बेहतर परफ़ॉर्मेंस वाले ऑडियो एपीआई, Khronos Group OpenSL ES 1.0.1 पर आधारित हैं. Khronos ने स्टैंडर्ड का नया वर्शन 1.1 रिलीज़ किया है. बदलाव किए गए वर्शन में नई सुविधाएं, जानकारी, टाइपो की गड़बड़ियों को ठीक करना, और कुछ ऐसी चीज़ें शामिल हैं जो काम नहीं करतीं. काम न करने की ज़्यादातर समस्याएं मामूली होती हैं या OpenSL ES के उन हिस्सों में होती हैं जो Android पर काम नहीं करते.

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

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

बाइनरी के साथ काम करने की सुविधा के लिए प्लान बनाना

हमारा सुझाव है कि आने वाले समय में बाइनरी के साथ काम करने की सुविधा को बेहतर बनाने के लिए, आपका ऐप्लिकेशन इन दिशा-निर्देशों का पालन करे:

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

ध्यान दें: ज़्यादा जानकारी के लिए, यहां दिया गया बफ़र कतार का व्यवहार सेक्शन देखें.

सोर्स के साथ काम करने के लिए प्लान

जैसा कि बताया गया है, Khronos Group के OpenSL ES के अगले वर्शन में, सोर्स कोड के काम न करने की समस्याएं आ सकती हैं. इनमें ये बदलाव हो सकते हैं:

  • बफ़र क्यू इंटरफ़ेस में काफ़ी बदलाव होने की उम्मीद है. खास तौर पर, BufferQueue::Enqueue, slBufferQueueCallback के पैरामीटर की सूची, और SLBufferQueueState.playIndex फ़ील्ड के नाम में. हमारा सुझाव है कि आपका ऐप्लिकेशन कोड इसके बजाय Android की आसान बफ़र लिस्ट का इस्तेमाल करें. NDK के साथ दिए गए उदाहरण के कोड में, हमने वीडियो चलाने के लिए Android की सिंपल बफ़र कतार का इस्तेमाल किया है. (हम PCM में रिकॉर्ड करने और डिकोड करने के लिए, Android की सिंपल बफ़र क्यू का भी इस्तेमाल करते हैं. ऐसा इसलिए है, क्योंकि स्टैंडर्ड OpenSL ES 1.0.1, बफ़र क्यू डेटा सिंक में रिकॉर्ड या डिकोड करने की सुविधा नहीं देता.)
  • रेफ़रंस के ज़रिए पास किए गए इनपुट पैरामीटर में const और इनपुट वैल्यू के तौर पर इस्तेमाल किए गए SLchar * स्ट्रक्चर फ़ील्ड में एक और एलिमेंट जोड़ा जाएगा. इसके लिए, आपको अपने कोड में कोई बदलाव करने की ज़रूरत नहीं है.
  • जिन पैरामीटर पर फ़िलहाल हस्ताक्षर किए गए हैं उन्हें हस्ताक्षर नहीं किए गए पैरामीटर से बदल दिया जाएगा. आपको पैरामीटर टाइप को SLint32 से SLuint32 या मिलते-जुलते टाइप में बदलना पड़ सकता है या कोई कास्ट जोड़ना पड़ सकता है.
  • Equalizer::GetPresetName, लागू करने की मेमोरी का पॉइंटर दिखाने के बजाय, स्ट्रिंग को ऐप्लिकेशन मेमोरी में कॉपी करता है. यह एक अहम बदलाव होगा. इसलिए, हमारा सुझाव है कि आप इस तरीके को कॉल करने से बचें या इसका इस्तेमाल अलग से करें.
  • स्ट्रक्चर टाइप में अतिरिक्त फ़ील्ड होंगे. आउटपुट पैरामीटर के लिए, इन नए फ़ील्ड को अनदेखा किया जा सकता है. हालांकि, इनपुट पैरामीटर के लिए, नए फ़ील्ड को शुरू करना होगा. सौभाग्य से, इन सभी फ़ील्ड को ऐसे इलाकों में इस्तेमाल किया जा सकता है जहां Android काम नहीं करता.
  • इंटरफ़ेस के GUID बदल जाएंगे. इंटरफ़ेस को GUID के बजाय, सिंबल वाले नाम से रेफ़र करें, ताकि किसी भी तरह की डिपेंडेंसी से बचा जा सके.
  • SLchar, unsigned char से बदलकर char हो जाएगा. इसका असर मुख्य रूप से, यूआरआई डेटा लोकेटर और MIME डेटा फ़ॉर्मैट पर पड़ता है.
  • SLDataFormat_MIME.mimeType का नाम बदलकर pMimeType कर दिया जाएगा और SLDataLocator_URI.URI का नाम बदलकर pURI कर दिया जाएगा. हमारा सुझाव है कि अपने कोड को इस बदलाव से अलग करने के लिए, SLDataFormat_MIME और SLDataLocator_URI डेटा स्ट्रक्चर को शुरू करने के लिए, फ़ील्ड के नाम के बजाय वैल्यू की ब्रैकेट वाली, कॉमा-सेपरेटेड लिस्ट का इस्तेमाल करें. इस तकनीक का इस्तेमाल, उदाहरण के तौर पर दिए गए कोड में किया गया है.
  • SL_DATAFORMAT_PCM, ऐप्लिकेशन को डेटा को साइन वाले पूर्णांक, बिना साइन वाले पूर्णांक या फ़्लोटिंग-पॉइंट के तौर पर दिखाने की अनुमति नहीं देता. Android को लागू करने के तरीके में यह माना जाता है कि 8-बिट डेटा को साइन नहीं किया गया पूर्णांक है और 16-बिट को साइन किया गया पूर्णांक है. इसके अलावा, samplesPerSec फ़ील्ड का नाम गलत है, क्योंकि इसकी असल इकाई मिलीहर्ट्ज़ है. उम्मीद है कि इन समस्याओं को OpenSL ES के अगले वर्शन में ठीक कर दिया जाएगा. इसमें एक नया एक्सटेंडेड PCM डेटा फ़ॉर्मैट जोड़ा जाएगा. इससे ऐप्लिकेशन को डेटा के बारे में साफ़ तौर पर बताने की अनुमति मिलेगी और फ़ील्ड का नाम ठीक हो जाएगा. यह एक नया डेटा फ़ॉर्मैट होगा और मौजूदा PCM डेटा फ़ॉर्मैट अब भी उपलब्ध रहेगा (हालांकि, इसे बंद कर दिया गया है). इसलिए, आपको अपने कोड में तुरंत कोई बदलाव करने की ज़रूरत नहीं होगी.