এই পৃষ্ঠায় আউটপুট লেটেন্সিতে কন্ট্রিবিউটরদের উপর ফোকাস করা হয়েছে, তবে ইনপুট লেটেন্সির ক্ষেত্রেও একই ধরনের আলোচনা প্রযোজ্য।
অ্যানালগ সার্কিট্রি উল্লেখযোগ্যভাবে অবদান রাখে না বলে ধরে নিলে, অডিও লেটেন্সিতে প্রধান সারফেস-লেভেল কন্ট্রিবিউটর হল নিম্নলিখিতগুলি:
- অ্যাপ্লিকেশন
- পাইপলাইনে মোট বাফারের সংখ্যা
- ফ্রেমের হিসেবে প্রতিটি বাফারের সাইজ
- অ্যাপ প্রসেসরের পরে অতিরিক্ত লেটেন্সি, যেমন ডিএসপি থেকে
উপরে উল্লিখিত কন্ট্রিবিউটরদের তালিকা যত নির্ভুলই হোক না কেন, এটি বিভ্রান্তিকরও। এর কারণ হল, বাফার সংখ্যা ও বাফার সাইজ হল প্রভাব, কারণ নয়। সাধারণত যা ঘটে তা হল একটি নির্দিষ্ট বাফার স্কিম প্রয়োগ এবং পরীক্ষা করা হয়, কিন্তু পরীক্ষার সময়, একটি অডিও আন্ডাররান বা ওভাররান "ক্লিক" বা "পপ" হিসাবে শোনা যায়। এর ক্ষতিপূরণ করতে, সিস্টেম ডিজাইনার বাফার সাইজ বা বাফার সংখ্যা বাড়িয়ে দেন। এর ফলে আন্ডাররান বা ওভাররান এড়ানো গেলেও, অবাঞ্ছিত পার্শ্বপ্রতিক্রিয়া হিসেবে লেটেন্সি বেড়ে যায়। বাফার সাইজ সম্পর্কে আরও জানতে, ভিডিও অডিও ল্যাটেন্সি: বাফার সাইজ দেখুন।
আন্ডাররান ও ওভাররানের কারণগুলি বোঝা এবং তারপরে সেগুলি সংশোধন করা হল আরও ভালো উপায়। এর ফলে শ্রুতিগোচর আর্টিফ্যাক্ট বাদ দেওয়া যায় এবং আরও ছোট বা কম বাফার ব্যবহার করা যায় এবং এর ফলে লেটেন্সি কমে যায়।
আমাদের অভিজ্ঞতা অনুসারে, আন্ডাররান ও ওভাররানের সবচেয়ে সাধারণ কারণগুলির মধ্যে এগুলি অন্তর্ভুক্ত:
- Linux CFS (Completely Fair Scheduler)
- SCHED_FIFO শিডিউলিং সহ উচ্চ-অগ্রাধিকার থ্রেড
- অগ্রাধিকারের ইনভার্সন
- শিডিউল করার ক্ষেত্রে দীর্ঘ লেটেন্সি
- দীর্ঘ সময় ধরে চলা ইন্টারাপ্ট হ্যান্ডলার
- দীর্ঘ ইন্টারাপ্ট বন্ধ করার সময়
- পাওয়ার ম্যানেজমেন্ট
- নিরাপত্তা কার্নেল
Linux CFS এবং SCHED_FIFO শিডিউলিং
Linux CFS এমনভাবে ডিজাইন করা হয়েছে যাতে একই CPU রিসোর্স শেয়ার করা ওয়ার্কলোডগুলির মধ্যে ভারসাম্য বজায় থাকে। এই ফেয়ারনেস প্রতিটি থ্রেডের nice প্যারামিটার দ্বারা দেখানো হয়। নাইস ভ্যালু -১৯ (সবচেয়ে কম নাইস বা সবচেয়ে বেশি CPU টাইম অ্যাসাইন করা) থেকে ২০ (সবচেয়ে বেশি নাইস বা সবচেয়ে কম CPU টাইম অ্যাসাইন করা) পর্যন্ত হয়। সাধারণত, নির্দিষ্ট নাইস ভ্যালু সহ সব থ্রেড প্রায় সমান সিপিইউ টাইম পায় এবং সংখ্যাগতভাবে কম নাইস ভ্যালু সহ থ্রেড আরও বেশি সিপিইউ টাইম পাবে বলে আশা করা হয়। তবে, CFS শুধুমাত্র তুলনামূলকভাবে দীর্ঘ পর্যবেক্ষণের সময়কালের উপর "ন্যায্য"। স্বল্প-মেয়াদী পর্যবেক্ষণ উইন্ডোতে, CFS অপ্রত্যাশিত উপায়ে CPU রিসোর্স বরাদ্দ করতে পারে। যেমন, এটি সংখ্যাগতভাবে কম 'নাইসনেস' থাকা থ্রেড থেকে সিপিইউ নিয়ে সংখ্যাগতভাবে বেশি 'নাইসনেস' থাকা থ্রেডে দিতে পারে। অডিওর ক্ষেত্রে, এর ফলে আন্ডাররান বা ওভাররান হতে পারে।
এর সহজ সমাধান হল, হাই-পারফর্ম্যান্স অডিও
থ্রেডের জন্য CFS এড়িয়ে যাওয়া। Android 4.1 থেকে শুরু করে, এই ধরনের থ্রেড এখন CFS-এর প্রয়োগ করা SCHED_NORMAL (এছাড়াও
SCHED_OTHER বলা হয়) শিডিউলিং নীতির পরিবর্তে
SCHED_FIFO শিডিউলিং নীতি ব্যবহার করে।
SCHED_FIFO প্রায়োরিটি
যদিও হাই-পারফর্ম্যান্স অডিও থ্রেড এখন SCHED_FIFO ব্যবহার করে, সেগুলি
অন্যান্য উচ্চ অগ্রাধিকারের SCHED_FIFO থ্রেডের প্রতি সংবেদনশীল।
এগুলি সাধারণত কার্নেল ওয়ার্কার থ্রেড, তবে নীতি SCHED_FIFO সহ কিছু
নন-অডিও ব্যবহারকারী থ্রেডও থাকতে পারে। উপলভ্য SCHED_FIFO
অগ্রাধিকারের রেঞ্জ ১ থেকে ৯৯ পর্যন্ত। অডিও থ্রেড ২ বা ৩
অগ্রাধিকার অনুযায়ী চলে। এর ফলে, কম অগ্রাধিকারযুক্ত থ্রেডের জন্য অগ্রাধিকার ১ উপলভ্য থাকে,
এবং বেশি অগ্রাধিকারযুক্ত থ্রেডের জন্য অগ্রাধিকার ৪ থেকে ৯৯ উপলভ্য থাকে। আমরা সাজেস্ট করি যে
সম্ভব হলে সবসময় অগ্রাধিকার ১ ব্যবহার করুন এবং যেসব থ্রেড নির্দিষ্ট সময়ের
মধ্যে সম্পূর্ণ হবে বলে গ্যারান্টি দেওয়া হয়, অডিও থ্রেডের সময়ের চেয়ে কম সময় ধরে এক্সিকিউট হয়
এবং অডিও থ্রেডের শিডিউলিংয়ে কোনও বাধা সৃষ্টি করে না বলে জানা যায়,
সেগুলির জন্য অগ্রাধিকার ৪ থেকে ৯৯ পর্যন্ত রিজার্ভ রাখুন।
রেট-মনোটনিক শিডিউলিং
স্থির অগ্রাধিকার অ্যাসাইন করার তত্ত্ব সম্পর্কে আরও তথ্যের জন্য, Wikipedia নিবন্ধ রেট-মনোটনিক শিডিউলিং (RMS) দেখুন। একটি গুরুত্বপূর্ণ বিষয় হল, নির্দিষ্ট অগ্রাধিকার কঠোরভাবে সময়সীমার উপর ভিত্তি করে বরাদ্দ করা উচিত, কম সময়সীমার থ্রেডকে বেশি অগ্রাধিকার দেওয়া উচিত, অনুভূত "গুরুত্বের" উপর ভিত্তি করে নয়। সর্বাধিক ফ্রিকোয়েন্সি অফ এক্সিকিউশন এবং এক্সিকিউশন পিছু সর্বাধিক কম্পিউটেশন ব্যবহার করে, নন-পিরিয়ডিক থ্রেডকে পিরিয়ডিক থ্রেড হিসেবে মডেল করা যেতে পারে। যদি কোনও নন-পিরিয়ডিক থ্রেডকে পিরিয়ডিক থ্রেড হিসেবে মডেল করা না যায় (যেমন, এটি আনবাউন্ডেড ফ্রিকোয়েন্সি বা আনবাউন্ডেড কম্পিউটেশন প্রতি এক্সিকিউশন সহ এক্সিকিউট করতে পারে), তাহলে এটিকে কোনও নির্দিষ্ট অগ্রাধিকার অ্যাসাইন করা উচিত নয়, কারণ এটি প্রকৃত পিরিয়ডিক থ্রেডের শিডিউলিংয়ের সাথে সামঞ্জস্যপূর্ণ হবে না।
অগ্রাধিকারের ইনভার্সন
অগ্রাধিকারের ইনভার্সন হল রিয়েল-টাইম সিস্টেমের একটি ক্লাসিক ব্যর্থতা মোড, যেখানে একটি উচ্চ-অগ্রাধিকার টাস্ক একটি আনবাউন্ডেড সময়ের জন্য ব্লক করা হয়, একটি নিম্ন-অগ্রাধিকার টাস্কের জন্য অপেক্ষা করে একটি রিসোর্স রিলিজ করার জন্য যেমন (শেয়ার করা স্টেট দ্বারা সুরক্ষিত) একটি মিউটেক্স। এটি কমানোর কৌশল জানতে "অগ্রাধিকার ইনভার্সন এড়ানো" নিবন্ধটি দেখুন।
শিডিউলিং লেটেন্সি
শিডিউলিং ল্যাটেন্সি হল সেই সময়সীমা যখন কোনও থ্রেড রান করার জন্য প্রস্তুত হয় এবং যখন ফলাফলস্বরূপ কনটেক্সট সুইচ সম্পূর্ণ হয় যাতে থ্রেডটি আসলে CPU-তে রান করে। লেটেন্সি যত কম হবে তত ভালো এবং দুই মিলিসেকেন্ডের বেশি হলে অডিওতে সমস্যা হয়। মোড ট্রানজিশনের সময় শিডিউলিং লেটেন্সি দীর্ঘ হওয়ার সম্ভাবনা সবচেয়ে বেশি থাকে, যেমন সিপিইউ চালু বা বন্ধ করা, নিরাপত্তা কার্নেল ও সাধারণ কার্নেলের মধ্যে পরিবর্তন করা, ফুল পাওয়ার থেকে কম-পাওয়ার মোডে পরিবর্তন করা, অথবা সিপিইউ ক্লক ফ্রিকোয়েন্সি ও ভোল্টেজ অ্যাডজাস্ট করা।
ইন্টারাপ্ট
অনেক ডিজাইনে, CPU 0 সব এক্সটার্নাল ইন্টারাপ্টকে পরিষেবা দেয়। তাই, অনেকক্ষণ ধরে চলা ইন্টারাপ্ট হ্যান্ডলার অন্যান্য ইন্টারাপ্টকে, বিশেষ করে
অডিও ডাইরেক্ট মেমরি অ্যাক্সেস (DMA) সম্পূর্ণ হওয়ার ইন্টারাপ্টকে
দেরি করিয়ে দিতে পারে। দ্রুত শেষ করার জন্য ইন্টারাপ্ট হ্যান্ডলার
ডিজাইন করুন এবং দীর্ঘ কাজকে থ্রেডে (বাঞ্ছনীয়
CFS থ্রেড বা SCHED_FIFO অগ্রাধিকার ১-এর থ্রেড) ডিফার করুন।
একইভাবে, CPU 0-তে দীর্ঘ সময়ের জন্য ইন্টারাপ্ট বন্ধ করে রাখলে অডিও ইন্টারাপ্ট সার্ভিসিংয়ে দেরি হওয়ার একই ফলাফল হয়। কার্নেলের স্পিন লক-এর জন্য অপেক্ষা করার সময় সাধারণত অনেকক্ষণ ধরে ইন্টারাপ্ট বন্ধ থাকে। এই স্পিন লকগুলি বাউন্ড করা আছে কিনা তা নিশ্চিত করতে সেগুলি পর্যালোচনা করুন।
পাওয়ার, পারফর্ম্যান্স ও থার্মাল ম্যানেজমেন্ট
পাওয়ার ম্যানেজমেন্ট হল একটি বিস্তৃত শব্দ যার মধ্যে পারফর্ম্যান্স অপ্টিমাইজ করার সময় বিদ্যুৎ খরচ মনিটর করা এবং কমানোর প্রচেষ্টা অন্তর্ভুক্ত। থার্মাল ম্যানেজমেন্ট এবং কম্পিউটার কুলিং একই ধরনের হলেও, অতিরিক্ত তাপের কারণে যাতে ক্ষতি না হয়, সেই জন্য তাপ পরিমাপ ও নিয়ন্ত্রণ করার চেষ্টা করে। Linux কার্নেলে, CPU গভর্নর নিম্ন-স্তরের নীতির জন্য দায়ী, যেখানে ব্যবহারকারী মোড উচ্চ-স্তরের নীতি কনফিগার করে। ব্যবহৃত টেকনিকের মধ্যে রয়েছে:
- ডায়নামিক ভোল্টেজ স্কেলিং
- ডায়নামিক ফ্রিকোয়েন্সি স্কেলিং
- ডায়নামিক কোর চালু করা
- ক্লাস্টার সুইচিং
- পাওয়ার গেটিং
- হটপ্লাগ (হটসোয়াপ)
- বিভিন্ন স্লিপ মোড (হাল্ট, স্টপ, আইডল, সাসপেন্ড ইত্যাদি)
- প্রসেস মাইগ্রেশন
- প্রসেসর অ্যাফিনিটি
কিছু ম্যানেজমেন্ট অপারেশনের ফলে "কাজ বন্ধ" হয়ে যেতে পারে অথবা এমন সময় আসতে পারে যখন অ্যাপ্লিকেশন প্রসেসর কোনও কাজের কাজ করে না। এইসব কাজ বন্ধ হয়ে গেলে অডিওতে সমস্যা হতে পারে, তাই অডিও অ্যাক্টিভ থাকার সময় সবচেয়ে খারাপ পরিস্থিতিতে কাজ বন্ধ হয়ে যাওয়ার মতো ঘটনা ম্যানেজ করার জন্য ডিজাইন করা উচিত। অবশ্যই, থার্মাল রানঅ্যাওয়ে আসন্ন হলে, স্থায়ী ক্ষতি এড়ানো অডিওর চেয়ে বেশি গুরুত্বপূর্ণ!
নিরাপত্তা কার্নেল
ডিজিটাল রাইটস ম্যানেজমেন্ট (DRM)-এর জন্য নিরাপত্তা কার্নেল প্রধান অপারেটিং সিস্টেম কার্নেল ও অ্যাপ্লিকেশন কোডের জন্য ব্যবহৃত একই অ্যাপ্লিকেশন প্রসেসর কোরে রান করতে পারে। কোনও নিরাপত্তা কার্নেল অপারেশন কোনও কোরে অ্যাক্টিভ থাকলে, সেই কোরে সাধারণত যে সাধারণ কাজ চলে তা কার্যত বন্ধ হয়ে যায়। বিশেষ করে, এর মধ্যে অডিও কাজ অন্তর্ভুক্ত থাকতে পারে। স্বভাবতই, নিরাপত্তা কার্নেলের অভ্যন্তরীণ আচরণ উচ্চ-স্তরের লেয়ার থেকে বোঝা যায় না এবং তাই নিরাপত্তা কার্নেলের কারণে হওয়া যেকোনও পারফর্ম্যান্সের অসঙ্গতি বিশেষভাবে ক্ষতিকারক। যেমন, নিরাপত্তা কার্নেল অপারেশন সাধারণত কনটেক্সট সুইচ ট্রেসে দেখা যায় না। আমরা একে "ডার্ক টাইম" বলি — যে সময় অতিবাহিত হয় অথচ তা পর্যবেক্ষণ করা যায় না। অডিও চালু থাকাকালীন গ্রহণযোগ্য সবচেয়ে খারাপ পরিস্থিতিতে কাজ বন্ধ হয়ে যাওয়া এড়ানোর জন্য নিরাপত্তা কার্নেল ডিজাইন করা উচিত।