অ্যান্ড্রয়েডের জন্য ওপেনএসএল ইএস

সতর্কতা: OpenSL ES অবচিত হয়েছে। ডেভেলপারদের ওপেন সোর্স Oboe লাইব্রেরি ব্যবহার করা উচিত যা GitHub এ উপলব্ধ। Oboe হল একটি C++ র‍্যাপার যা একটি API প্রদান করে যা AAudio-এর সাথে সাদৃশ্যপূর্ণ। AAudio উপলব্ধ থাকলে Oboe AAudio-কে কল করে এবং AAudio উপলব্ধ না হলে OpenSL ES-এ ফিরে আসে৷

OpenSL ES™-এর NDK বাস্তবায়ন কীভাবে OpenSL ES 1.0.1-এর রেফারেন্স স্পেসিফিকেশন থেকে আলাদা সে সম্পর্কে এই পৃষ্ঠাটি বিশদ প্রদান করে। স্পেসিফিকেশন থেকে নমুনা কোড ব্যবহার করার সময়, আপনাকে Android এ কাজ করার জন্য এটি সংশোধন করতে হতে পারে।

অন্যথায় উল্লেখ করা না থাকলে, সমস্ত বৈশিষ্ট্য Android 2.3 (API স্তর 9) এবং উচ্চতর সংস্করণে উপলব্ধ। কিছু বৈশিষ্ট্য শুধুমাত্র Android 4.0 (API স্তর 14) এর জন্য উপলব্ধ; এগুলো উল্লেখ করা হয়।

দ্রষ্টব্য: Android কম্প্যাটিবিলিটি ডেফিনিশন ডকুমেন্ট (CDD) একটি সামঞ্জস্যপূর্ণ Android ডিভাইসের হার্ডওয়্যার এবং সফ্টওয়্যার প্রয়োজনীয়তাগুলি গণনা করে৷ সামগ্রিক সামঞ্জস্যতা প্রোগ্রাম সম্পর্কে আরও তথ্যের জন্য অ্যান্ড্রয়েড সামঞ্জস্যতা এবং প্রকৃত CDD নথির জন্য CDD দেখুন৷

OpenSL ES একটি C ভাষা ইন্টারফেস প্রদান করে যা C++ ব্যবহার করেও অ্যাক্সেসযোগ্য। এটি এই অ্যান্ড্রয়েড জাভা API-এর অডিও অংশগুলির মতো বৈশিষ্ট্যগুলিকে প্রকাশ করে:

সমস্ত অ্যান্ড্রয়েড নেটিভ ডেভেলপমেন্ট কিট (এনডিকে) এর মতো, অ্যান্ড্রয়েডের জন্য ওপেনএসএল ইএস-এর প্রাথমিক উদ্দেশ্য হল জাভা নেটিভ ইন্টারফেস ( জেএনআই ) ব্যবহার করে কল করা শেয়ার্ড লাইব্রেরিগুলি বাস্তবায়নের সুবিধা দেওয়া। NDK বিশুদ্ধ C/C++ অ্যাপ্লিকেশন লেখার উদ্দেশ্যে নয়। যাইহোক, OpenSL ES হল একটি পূর্ণ-বৈশিষ্ট্যযুক্ত API, এবং আমরা আশা করি যে আপনি Android রানটাইমে চলমান কোডে আপ-কল না করে শুধুমাত্র এই API ব্যবহার করে আপনার বেশিরভাগ অডিও চাহিদা পূরণ করতে সক্ষম হবেন।

দ্রষ্টব্য: যদিও ওপেনএসএল ইএস-এর উপর ভিত্তি করে, অ্যান্ড্রয়েড নেটিভ অডিও (উচ্চ-পারফরম্যান্স অডিও) এপিআই কোনও OpenSL ES 1.0.1 প্রোফাইলের (গেম, মিউজিক, বা ফোন) সাথে সামঞ্জস্যপূর্ণ বাস্তবায়ন নয়। এর কারণ হল Android কোনো একটি প্রোফাইলের জন্য প্রয়োজনীয় সমস্ত বৈশিষ্ট্য বাস্তবায়ন করে না। যেকোন পরিচিত কেস যেখানে Android স্পেসিফিকেশনের চেয়ে ভিন্নভাবে আচরণ করে Android এক্সটেনশন পৃষ্ঠায় বর্ণনা করা হয়েছে।

রেফারেন্স স্পেসিফিকেশন থেকে উত্তরাধিকারসূত্রে প্রাপ্ত বৈশিষ্ট্য

OpenSL ES-এর Android NDK বাস্তবায়ন কিছু নির্দিষ্ট সীমাবদ্ধতা সহ রেফারেন্স স্পেসিফিকেশন থেকে সেট করা অনেক বৈশিষ্ট্য উত্তরাধিকার সূত্রে পায়।

গ্লোবাল এন্ট্রি পয়েন্ট

অ্যান্ড্রয়েডের জন্য OpenSL ES অ্যান্ড্রয়েড স্পেসিফিকেশনের সমস্ত গ্লোবাল এন্ট্রি পয়েন্ট সমর্থন করে। এই এন্ট্রি পয়েন্ট অন্তর্ভুক্ত:

  • slCreateEngine
  • slQueryNumSupportedEngineInterfaces
  • slQuerySupportedEngineInterfaces

অবজেক্ট এবং ইন্টারফেস

নিম্নলিখিত সারণীটি ওপেনএসএল ইএস-এর অ্যান্ড্রয়েড এনডিকে বাস্তবায়ন সমর্থন করে এমন বস্তু এবং ইন্টারফেসগুলি দেখায়। যদি ঘরে একটি হ্যাঁ উপস্থিত হয়, তাহলে এই বাস্তবায়নে বৈশিষ্ট্যটি উপলব্ধ।

বস্তু এবং ইন্টারফেসের জন্য Android NDK সমর্থন।

বৈশিষ্ট্য অডিও প্লেয়ার অডিও রেকর্ডার ইঞ্জিন আউটপুট মিশ্রণ
খাদ বুস্ট হ্যাঁ না না হ্যাঁ
বাফার সারি হ্যাঁ না না না
বাফার সারি ডেটা লোকেটার হ্যাঁ: উত্স না না না
গতিশীল ইন্টারফেস ব্যবস্থাপনা হ্যাঁ হ্যাঁ হ্যাঁ হ্যাঁ
প্রভাব পাঠান হ্যাঁ না না না
ইঞ্জিন না না হ্যাঁ না
এনভায়রনমেন্টাল রিভার্ব না না না হ্যাঁ
ইকুয়ালাইজার হ্যাঁ না না হ্যাঁ
I/O ডিভাইস ডেটা লোকেটার না হ্যাঁ: উত্স না না
মেটাডেটা নিষ্কাশন হ্যাঁ: PCM-এ ডিকোড করুন না না না
নিঃশব্দ একা হ্যাঁ না না না
অবজেক্ট হ্যাঁ হ্যাঁ হ্যাঁ হ্যাঁ
আউটপুট মিশ্রণ লোকেটার হ্যাঁ: সিঙ্ক না না না
খেলা হ্যাঁ না না না
প্লেব্যাক হার হ্যাঁ না না না
প্রিফেচ স্ট্যাটাস হ্যাঁ না না না
পূর্বনির্ধারিত reverb না না না হ্যাঁ
রেকর্ড না হ্যাঁ না না
খোঁজ হ্যাঁ না না না
URI ডেটা লোকেটার হ্যাঁ: উত্স না না না
ভার্চুয়ালাইজার হ্যাঁ না না হ্যাঁ
আয়তন হ্যাঁ না না না

পরবর্তী বিভাগে এই বৈশিষ্ট্যগুলির কিছুর সীমাবদ্ধতা ব্যাখ্যা করা হয়েছে।

সীমাবদ্ধতা

কিছু নির্দিষ্ট সীমাবদ্ধতা সারণি 1 এর বৈশিষ্ট্যগুলিতে প্রযোজ্য৷ এই সীমাবদ্ধতাগুলি রেফারেন্স স্পেসিফিকেশন থেকে পার্থক্যগুলিকে উপস্থাপন করে৷ এই বিভাগের বাকি অংশ এই পার্থক্য সম্পর্কে তথ্য প্রদান করে।

গতিশীল ইন্টারফেস ব্যবস্থাপনা

Android এর জন্য OpenSL ES RemoveInterface বা ResumeInterface সমর্থন করে না।

ইফেক্ট কম্বিনেশন: এনভায়রনমেন্ট রিভার্ব এবং প্রিসেট রিভার্ব

একই আউটপুট মিশ্রণে আপনার পরিবেশগত রিভার্ব এবং প্রিসেট রিভার্ব উভয়ই থাকতে পারে না।

প্ল্যাটফর্ম প্রভাব অনুরোধ উপেক্ষা করতে পারে যদি এটি অনুমান করে যে CPU লোড খুব বেশি হবে।

প্রভাব পাঠান

SetSendLevel() অডিও প্লেয়ার প্রতি একটি একক প্রেরণ স্তর সমর্থন করে।

এনভায়রনমেন্টাল রিভার্ব

এনভায়রনমেন্টাল রিভার্ব SLEnvironmentalReverbSettings struct এর reflectionsDelay , reflectionsLevel , বা reverbDelay ক্ষেত্র সমর্থন করে না।

MIME ডেটা বিন্যাস

আপনি MIME ডেটা বিন্যাসটি শুধুমাত্র URI ডেটা লোকেটারের সাথে এবং শুধুমাত্র একটি অডিও প্লেয়ারের জন্য ব্যবহার করতে পারেন। আপনি একটি অডিও রেকর্ডার জন্য এই তথ্য বিন্যাস ব্যবহার করতে পারবেন না.

OpenSL ES-এর অ্যান্ড্রয়েড বাস্তবায়নের জন্য আপনাকে mimeType NULL বা একটি বৈধ UTF-8 স্ট্রিং-এ আরম্ভ করতে হবে। আপনাকে অবশ্যই একটি বৈধ মানের containerType শুরু করতে হবে। অন্যান্য বিবেচনার অনুপস্থিতিতে, যেমন অন্যান্য বাস্তবায়নের পোর্টেবিলিটি বা বিষয়বস্তু বিন্যাস যা একটি অ্যাপ শিরোনাম দ্বারা সনাক্ত করতে পারে না, আমরা সুপারিশ করি যে আপনি mimeType কে NULL এবং containerType SL_CONTAINERTYPE_UNSPECIFIED এ সেট করুন৷

অ্যান্ড্রয়েডের জন্য OpenSL ES নিম্নলিখিত অডিও ফর্ম্যাটগুলিকে সমর্থন করে, যতক্ষণ না অ্যান্ড্রয়েড প্ল্যাটফর্ম তাদের সমর্থন করে:

  • WAV PCM।
  • WAV আলাও।
  • WAV উলাও.
  • MP3 Ogg Vorbis.
  • এএসি এলসি।
  • HE-AACv1 (AAC+)।
  • HE-AACv2 (বর্ধিত AAC+)।
  • এএমআর
  • FLAC

দ্রষ্টব্য: অ্যান্ড্রয়েড সমর্থন করে এমন অডিও ফর্ম্যাটের একটি তালিকার জন্য, সমর্থিত মিডিয়া ফর্ম্যাটগুলি দেখুন৷

ওপেনএসএল ইএস-এর এই বাস্তবায়নে এই এবং অন্যান্য ফরম্যাটগুলির পরিচালনার ক্ষেত্রে নিম্নলিখিত সীমাবদ্ধতাগুলি প্রযোজ্য:

  • AAC ফর্ম্যাটগুলি অবশ্যই একটি MP4 বা ADTS কন্টেইনারের মধ্যে থাকতে হবে৷
  • Android এর জন্য OpenSL ES MIDI সমর্থন করে না।
  • WMA AOSP এর অংশ নয়, এবং আমরা Android এর জন্য OpenSL ES এর সাথে এর সামঞ্জস্য যাচাই করিনি।
  • OpenSL ES এর Android NDK বাস্তবায়ন DRM বা এনক্রিপ্ট করা সামগ্রীর সরাসরি প্লেব্যাক সমর্থন করে না। সুরক্ষিত অডিও কন্টেন্ট প্লে ব্যাক করতে, আপনার অ্যাপের সাথে যেকোনো DRM বিধিনিষেধ প্রয়োগ করে প্লে করার আগে আপনাকে অবশ্যই এটিকে আপনার অ্যাপ্লিকেশনে ডিক্রিপ্ট করতে হবে।

অ্যান্ড্রয়েডের জন্য OpenSL ES অবজেক্ট ম্যানিপুলেট করার জন্য নিম্নলিখিত পদ্ধতিগুলিকে সমর্থন করে না:

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

PCM ডেটা বিন্যাস

PCM হল একমাত্র ডেটা বিন্যাস যা আপনি বাফার সারিগুলির সাথে ব্যবহার করতে পারেন। সমর্থিত PCM প্লেব্যাক কনফিগারেশনের নিম্নলিখিত বৈশিষ্ট্য রয়েছে:

  • 8-বিট স্বাক্ষরবিহীন বা 16-বিট স্বাক্ষরিত।
  • মনো বা স্টেরিও।
  • লিটল-এন্ডিয়ান বাইট অর্ডারিং।
  • এর নমুনা হার:
    • 8,000 Hz
    • 11,025 Hz
    • 12,000 Hz
    • 16,000 Hz
    • 22,050 Hz
    • 24,000 Hz
    • 32,000 Hz
    • 44,100 Hz
    • 48,000 Hz

অ্যান্ড্রয়েডের জন্য OpenSL ES যে কনফিগারেশনগুলি রেকর্ডিংয়ের জন্য সমর্থন করে তা ডিভাইস-নির্ভর; সাধারণত, ডিভাইস নির্বিশেষে 16,000 Hz mono/16-বিট স্বাক্ষরিত উপলব্ধ।

বিভ্রান্তিকর নাম থাকা সত্ত্বেও samplesPerSec ফিল্ডের মান মিলিহার্জের এককে। দুর্ঘটনাক্রমে ভুল মান ব্যবহার এড়াতে, আমরা সুপারিশ করি যে আপনি এই উদ্দেশ্যে সংজ্ঞায়িত প্রতীকী ধ্রুবকগুলির একটি ব্যবহার করে এই ক্ষেত্রটি শুরু করুন, যেমন SL_SAMPLINGRATE_44_1 ।

Android 5.0 (API স্তর 21) এবং তার উপরে ফ্লোটিং-পয়েন্ট ডেটা সমর্থন করে।

প্লেব্যাক হার

একটি ওপেনএসএল ইএস প্লেব্যাক রেট নির্দেশ করে যে গতিতে একটি বস্তু ডেটা উপস্থাপন করে, স্বাভাবিক গতির হাজার ভাগে বা প্রতি মিলে প্রকাশ করে। উদাহরণস্বরূপ, 1,000 প্রতি মিলের একটি প্লেব্যাক রেট হল 1,000/1,000, বা স্বাভাবিক গতি৷ একটি হারের পরিসর হল একটি বন্ধ ব্যবধান যা সম্ভাব্য প্লেব্যাক হারের একটি পরিসীমা প্রকাশ করে।

প্লেব্যাক রেট রেঞ্জ এবং অন্যান্য ক্ষমতাগুলির জন্য সমর্থন প্ল্যাটফর্ম সংস্করণ এবং বাস্তবায়নের উপর নির্ভর করে পরিবর্তিত হতে পারে। আপনার অ্যাপ রানটাইমে এই ক্ষমতাগুলি নির্ধারণ করতে পারে PlaybackRate::GetRateRange() বা PlaybackRate::GetCapabilitiesOfRate() ব্যবহার করে ডিভাইসটি জিজ্ঞাসা করতে।

একটি ডিভাইস সাধারণত পিসিএম ফরম্যাটে ডেটা সোর্সের জন্য একই হারের সীমা সমর্থন করে এবং অন্যান্য ফরম্যাটের জন্য 1000 থেকে 1000 প্রতি মিলি পর্যন্ত একতা হারের পরিসীমা সমর্থন করে; অর্থাৎ, ঐক্য হার পরিসীমা কার্যকরভাবে একটি একক মান।

রেকর্ড

Android এর জন্য OpenSL ES SL_RECORDEVENT_HEADATLIMIT বা SL_RECORDEVENT_HEADMOVING ইভেন্ট সমর্থন করে না।

খোঁজ

SetLoop() পদ্ধতি পুরো ফাইল লুপিং সক্ষম করে। লুপিং সক্ষম করতে, startPos প্যারামিটার 0 এ সেট করুন এবং endPos প্যারামিটার SL_TIME_UNKNOWN এ সেট করুন।

বাফার সারি ডেটা লোকেটার

একটি বাফার সারির জন্য ডেটা লোকেটার সহ একটি অডিও প্লেয়ার বা রেকর্ডার শুধুমাত্র PCM ডেটা বিন্যাস সমর্থন করে।

I/O ডিভাইস ডেটা লোকেটার

অ্যান্ড্রয়েডের জন্য OpenSL ES শুধুমাত্র একটি I/O ডিভাইস ডেটা লোকেটার ব্যবহার সমর্থন করে যখন আপনি Engine::CreateAudioRecorder() এর জন্য ডেটা উৎস হিসাবে লোকেটারকে নির্দিষ্ট করেছেন। নিম্নলিখিত কোড স্নিপেটে থাকা মানগুলি ব্যবহার করে ডিভাইস ডেটা লোকেটার শুরু করুন:

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

URI ডেটা লোকেটার

অ্যান্ড্রয়েডের জন্য OpenSL ES শুধুমাত্র MIME ডেটা বিন্যাস সহ URI ডেটা লোকেটার ব্যবহার করতে পারে এবং শুধুমাত্র একটি অডিও প্লেয়ারের জন্য। আপনি একটি অডিও রেকর্ডারের জন্য একটি URI ডেটা লোকেটার ব্যবহার করতে পারবেন না৷ URI শুধুমাত্র http: এবং file: স্কিম ব্যবহার করতে পারে। অন্যান্য স্কিম, যেমন https: , ftp: , বা content: অনুমোদিত নয়।

আমরা rtsp: Android প্ল্যাটফর্মে অডিও সহ সমর্থন যাচাই করিনি।

ডেটা স্ট্রাকচার

অ্যান্ড্রয়েড এই OpenSL ES 1.0.1 ডেটা স্ট্রাকচার সমর্থন করে:

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

প্ল্যাটফর্ম কনফিগারেশন

অ্যান্ড্রয়েডের জন্য OpenSL ES বহু-থ্রেডেড অ্যাপ্লিকেশনের জন্য ডিজাইন করা হয়েছে এবং থ্রেড-নিরাপদ। এটি প্রতি অ্যাপ্লিকেশনে একটি একক ইঞ্জিন এবং প্রতি ইঞ্জিনে 32টি অবজেক্ট পর্যন্ত সমর্থন করে। উপলব্ধ ডিভাইস মেমরি এবং CPU বস্তুর ব্যবহারযোগ্য সংখ্যাকে আরও সীমাবদ্ধ করতে পারে।

এই ইঞ্জিন বিকল্পগুলি স্বীকৃত, কিন্তু সেগুলি 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 স্পেসিফিকেশনের একটি অনুলিপি অন্তর্ভুক্ত করেছি।

প্ল্যাটফর্ম সমস্যা

এই বিভাগটি প্রাথমিক প্ল্যাটফর্ম রিলিজে পরিচিত সমস্যাগুলি বর্ণনা করে যা এই APIগুলিকে সমর্থন করে।

গতিশীল ইন্টারফেস ব্যবস্থাপনা

DynamicInterfaceManagement::AddInterface কাজ করে না। পরিবর্তে, অ্যারেতে ইন্টারফেসটি নির্দিষ্ট করুন যা Create() এ পাস করা হয়েছে, যেমনটি পরিবেশগত রিভার্বের উদাহরণ কোডে দেখানো হয়েছে।

OpenSL ES এর ভবিষ্যত সংস্করণের জন্য পরিকল্পনা করুন

অ্যান্ড্রয়েড হাই-পারফরম্যান্স অডিও APIগুলি খরোনোস গ্রুপ ওপেনএসএল ইএস 1.0.1 এর উপর ভিত্তি করে তৈরি। খরোনোস স্ট্যান্ডার্ডের একটি সংশোধিত সংস্করণ 1.1 প্রকাশ করেছে। সংশোধিত সংস্করণে নতুন বৈশিষ্ট্য, স্পষ্টীকরণ, টাইপোগ্রাফিক ত্রুটির সংশোধন এবং কিছু অসঙ্গতি রয়েছে। বেশিরভাগ প্রত্যাশিত অসামঞ্জস্যতা তুলনামূলকভাবে ছোট বা OpenSL ES এর এলাকায় যা Android দ্বারা সমর্থিত নয়।

এই সংস্করণের সাথে তৈরি করা একটি অ্যাপ্লিকেশন Android প্ল্যাটফর্মের ভবিষ্যত সংস্করণগুলিতে কাজ করা উচিত, যদি আপনি নীচের বাইনারি সামঞ্জস্যের জন্য পরিকল্পনা বিভাগে বর্ণিত নির্দেশিকাগুলি অনুসরণ করেন৷

দ্রষ্টব্য: ভবিষ্যতের উত্স সামঞ্জস্য একটি লক্ষ্য নয়। অর্থাৎ, আপনি যদি NDK-এর একটি নতুন সংস্করণে আপগ্রেড করেন, তাহলে আপনাকে নতুন API-এর সাথে সামঞ্জস্য করতে আপনার অ্যাপ্লিকেশন সোর্স কোড পরিবর্তন করতে হতে পারে। আমরা আশা করি যে এই ধরনের বেশিরভাগ পরিবর্তন ছোটখাট হবে; নীচে বিস্তারিত দেখুন।

বাইনারি সামঞ্জস্যের জন্য পরিকল্পনা

আমরা সুপারিশ করি যে ভবিষ্যতে বাইনারি সামঞ্জস্য উন্নত করতে আপনার অ্যাপ্লিকেশন এই নির্দেশিকাগুলি অনুসরণ করুন:

  • OpenSL ES 1.0.1 থেকে শুধুমাত্র Android-সমর্থিত বৈশিষ্ট্যগুলির নথিভুক্ত উপসেট ব্যবহার করুন।
  • একটি অসফল অপারেশনের জন্য একটি নির্দিষ্ট ফলাফল কোডের উপর নির্ভর করবেন না; একটি ভিন্ন ফলাফল কোড মোকাবেলা করতে প্রস্তুত থাকুন।
  • অ্যাপ্লিকেশন কলব্যাক হ্যান্ডলারগুলি সাধারণত একটি সীমাবদ্ধ প্রেক্ষাপটে চলে। তাদের কাজ দ্রুত সম্পাদন করার জন্য লেখা উচিত, এবং তারপর যত তাড়াতাড়ি সম্ভব ফিরে আসবে। একটি কলব্যাক হ্যান্ডলারের মধ্যে জটিল অপারেশন চালাবেন না। উদাহরণস্বরূপ, একটি বাফার সারি সমাপ্তির কলব্যাকের মধ্যে, আপনি অন্য একটি বাফার সারিবদ্ধ করতে পারেন, কিন্তু একটি অডিও প্লেয়ার তৈরি করবেন না।
  • কলব্যাক হ্যান্ডলারদেরকে কমবেশি ঘন ঘন কল করার জন্য, অতিরিক্ত ইভেন্টের ধরন পাওয়ার জন্য প্রস্তুত থাকতে হবে এবং ইভেন্টের ধরনগুলিকে উপেক্ষা করা উচিত যা তারা চিনতে পারে না। যে কলব্যাকগুলি সক্রিয় ইভেন্ট প্রকারের তৈরি একটি ইভেন্ট মাস্কের সাথে কনফিগার করা হয়েছে সেগুলিকে একই সাথে একাধিক ইভেন্ট টাইপ বিট সেটের সাথে কল করার জন্য প্রস্তুত করা উচিত৷ একটি সুইচ কেসের পরিবর্তে প্রতিটি ইভেন্ট বিটের জন্য পরীক্ষা করতে "&" ব্যবহার করুন।
  • অগ্রগতির সাধারণ ইঙ্গিত হিসাবে প্রিফেচ স্ট্যাটাস এবং কলব্যাকগুলি ব্যবহার করুন, তবে নির্দিষ্ট হার্ড-কোডেড ফিল লেভেল বা কলব্যাক সিকোয়েন্সের উপর নির্ভর করবেন না। প্রিফেচ স্ট্যাটাস ফিল লেভেলের অর্থ, এবং প্রিফেচের সময় শনাক্ত করা ত্রুটির আচরণ পরিবর্তন হতে পারে।

দ্রষ্টব্য: আরও বিশদ বিবরণের জন্য নীচের বাফার সারি আচরণ বিভাগটি দেখুন।

উত্স সামঞ্জস্যের জন্য পরিকল্পনা

যেমন উল্লেখ করা হয়েছে, খ্রোনোস গ্রুপ থেকে OpenSL ES-এর পরবর্তী সংস্করণে সোর্স কোডের অসঙ্গতি প্রত্যাশিত। পরিবর্তনের সম্ভাব্য ক্ষেত্রগুলির মধ্যে রয়েছে:

  • বাফার কিউ ইন্টারফেসে উল্লেখযোগ্য পরিবর্তন হবে বলে আশা করা হচ্ছে, বিশেষ করে BufferQueue::Enqueue , slBufferQueueCallback এর প্যারামিটার তালিকা এবং SLBufferQueueState.playIndex ক্ষেত্রের নাম। আমরা সুপারিশ করি যে আপনার অ্যাপ্লিকেশন কোড পরিবর্তে Android সাধারণ বাফার সারি ব্যবহার করুন। NDK-এর সাথে সরবরাহ করা উদাহরণ কোডে, আমরা এই কারণে প্লেব্যাকের জন্য Android সাধারণ বাফার কিউ ব্যবহার করেছি। (পিসিএম-এ রেকর্ডিং এবং ডিকোডিংয়ের জন্য আমরা অ্যান্ড্রয়েড সাধারণ বাফার সারিও ব্যবহার করি, তবে এটির কারণ হল স্ট্যান্ডার্ড ওপেনএসএল ইএস 1.0.1 বাফার কিউ ডেটা সিঙ্কে রেকর্ড বা ডিকোড সমর্থন করে না।)
  • রেফারেন্স দ্বারা পাস করা ইনপুট প্যারামিটারে এবং ইনপুট মান হিসাবে ব্যবহৃত SLchar * struct ক্ষেত্রগুলিতে const যোগ করা হবে। এটি আপনার কোডে কোন পরিবর্তন প্রয়োজন হবে না.
  • বর্তমানে স্বাক্ষরিত কিছু প্যারামিটারের জন্য স্বাক্ষরবিহীন প্রকারের একটি প্রতিস্থাপন করা হবে। আপনাকে একটি প্যারামিটার প্রকার SLint32 থেকে SLuint32 বা অনুরূপ পরিবর্তন করতে হতে পারে, অথবা একটি কাস্ট যোগ করতে হবে।
  • Equalizer::GetPresetName বাস্তবায়ন মেমরিতে একটি পয়েন্টার ফেরত দেওয়ার পরিবর্তে অ্যাপ্লিকেশন মেমরিতে স্ট্রিংটি অনুলিপি করে। এটি একটি উল্লেখযোগ্য পরিবর্তন হবে, তাই আমরা সুপারিশ করছি যে আপনি হয় এই পদ্ধতিতে কল করা এড়িয়ে চলুন, অথবা আপনার ব্যবহারকে আলাদা করুন৷
  • struct প্রকারের অতিরিক্ত ক্ষেত্র থাকবে। আউটপুট পরামিতিগুলির জন্য, এই নতুন ক্ষেত্রগুলি উপেক্ষা করা যেতে পারে, তবে ইনপুট পরামিতির জন্য নতুন ক্ষেত্রগুলিকে আরম্ভ করতে হবে। সৌভাগ্যবশত, এই সমস্ত ক্ষেত্রগুলি Android দ্বারা সমর্থিত নয় এমন এলাকায় হবে বলে আশা করা হচ্ছে৷
  • ইন্টারফেস GUID পরিবর্তন হবে। নির্ভরতা এড়াতে GUID-এর পরিবর্তে প্রতীকী নাম দ্বারা ইন্টারফেসগুলি পড়ুন।
  • SLchar unsigned char থেকে char -এ পরিবর্তিত হবে। এটি প্রাথমিকভাবে URI ডেটা লোকেটার এবং MIME ডেটা বিন্যাসকে প্রভাবিত করে৷
  • SLDataFormat_MIME.mimeType এর নাম পরিবর্তন করে pMimeType করা হবে, এবং SLDataLocator_URI.URI নাম পরিবর্তন করে pURI করা হবে। আমরা সুপারিশ করছি যে আপনি SLDataFormat_MIME এবং SLDataLocator_URI ডেটা স্ট্রাকচারগুলিকে এই পরিবর্তন থেকে আপনার কোডকে বিচ্ছিন্ন করতে ক্ষেত্রের নামের পরিবর্তে একটি বন্ধনী-ঘেরা, কমা-বিভাজিত মানগুলির তালিকা ব্যবহার করে শুরু করুন৷ এই কৌশলটি উদাহরণ কোডে ব্যবহৃত হয়।
  • SL_DATAFORMAT_PCM অ্যাপ্লিকেশনটিকে স্বাক্ষরিত পূর্ণসংখ্যা, স্বাক্ষরবিহীন পূর্ণসংখ্যা বা ভাসমান-বিন্দু হিসাবে ডেটার উপস্থাপনা নির্দিষ্ট করার অনুমতি দেয় না। অ্যান্ড্রয়েড বাস্তবায়ন অনুমান করে যে 8-বিট ডেটা স্বাক্ষরবিহীন পূর্ণসংখ্যা এবং 16-বিট স্বাক্ষরিত পূর্ণসংখ্যা। উপরন্তু, ক্ষেত্রের samplesPerSec একটি ভুল নাম, কারণ প্রকৃত একক হল milliHz। এই সমস্যাগুলি পরবর্তী OpenSL ES সংস্করণে সমাধান করা হবে বলে আশা করা হচ্ছে, যা একটি নতুন বর্ধিত PCM ডেটা বিন্যাস প্রবর্তন করবে যা অ্যাপ্লিকেশনটিকে স্পষ্টভাবে উপস্থাপনা নির্দিষ্ট করতে এবং ক্ষেত্রের নাম সংশোধন করার অনুমতি দেয়। যেহেতু এটি একটি নতুন ডেটা বিন্যাস হবে, এবং বর্তমান PCM ডেটা বিন্যাসটি এখনও উপলব্ধ থাকবে (যদিও অবমূল্যায়ন করা হয়েছে), এটির জন্য আপনার কোডে কোনো তাত্ক্ষণিক পরিবর্তনের প্রয়োজন হবে না।