CPU ব্যবহার কম, তবু অডিও কেটে যায় কেন? — বাফার ও ডেডলাইন থেকে বোঝা

গান শোনার সময় মাঝে মাঝে অডিও “পট্” করে কেটে যায়। Task Manager-এ CPU ব্যবহার 10%-এর আশেপাশে, অথচ শুধু অডিওই স্থির থাকে না। এমন ক্ষেত্রে, CPU-তে যথেষ্ট ফাঁকা ক্ষমতা থাকা সত্ত্বেও অডিও কেটে যায় কেন?

CPU ব্যবহার কম হলেও, পরের অডিও ডেটার পূরণ ডেডলাইনের মধ্যে না পৌঁছালে অডিও কেটে যেতে পারে। কারণ, বাফারে থাকা অডিও বাজতে বাজতেই পরের ডেটা দিয়ে দিতে হয়। ডেটা বা লকের অপেক্ষা, কিংবা দরকারি লজিক্যাল CPU-তে DPC/ISR-এর মতো কারণে পূরণে দেরি পুরো CPU পুরোপুরি ব্যবহার না হলেও ঘটতে পারে। Exclusive-Mode Streams, CPU Analysis

তবে শুধু কানে শোনা “পট্” শব্দ দিয়ে একে আন্ডাররান বলে নিশ্চিত হওয়া যায় না। অডিও সোর্স, অ্যাপ, অডিও ইফেক্ট, আউটপুট ডিভাইস ইত্যাদি থেকেও একই রকম উপসর্গ দেখা দেয়। প্রথমে একই অডিও সোর্সে একবারে একটি শর্ত বদলে আবার আগের অবস্থায় ফিরিয়ে তুলনা করুন; তাতেও পরিসর ছোট না হলে ড্রপআউটের আগে-পরের সময় রেকর্ড করুন। Fix distorted or crackling audio in Windows

এই নিবন্ধ সেই প্রশ্ন, এবং তার পরের প্রশ্ন “বাফার বড় করলেই কি চলবে?” ও “কী তুলনা করলে আর কী রেকর্ড করলে কারণের পরিসর ছোট করা যায়?” নিয়ে আলোচনা করে। শুধু CPU ব্যবহার বা কানে শোনা শব্দ দিয়ে কোনো নির্দিষ্ট সমস্যার কারণ নিশ্চিত করা এর উদ্দেশ্য নয়।

মূল লক্ষ্য Windows 11-এ অডিও আউটপুট। বিল্ট-ইন, তারযুক্ত, USB, Bluetooth ইত্যাদি আউটপুট তুলনার আওতায় আছে, আর মিউজিক প্রোডাকশন সফটওয়্যার (DAW)-এর ক্ষেত্রে অ্যাপ বা ড্রাইভার বাফার সেটিং দিলে সেই তুলনাও আলোচনা করা হয়েছে। পুরো রেকর্ডিং ব্যবস্থার ডিজাইন বা প্রতিটি ডিভাইসের ওয়্যারলেস যোগাযোগের ডায়াগনসিস এখানে পুরোপুরি আলোচিত হয়নি।

ব্যাখ্যায় শেয়ার্ড মোডকে মূল উদাহরণ হিসেবে নেওয়া হয়েছে। আসল পথ, বাফারের পরিমাণ ও প্রসেসিং পিরিয়ড অ্যাপ, API, ড্রাইভার ও ডিভাইসভেদে আলাদা, আর সব অ্যাপে একই রকম কোনো বাফার সেটিং স্ক্রিনও নেই। Low Latency Audio

এখানে দেখানো CPU ব্যবহার, 10 মিলিসেকেন্ডের অবশিষ্ট ডেটা, পূরণের সময় ইত্যাদি ব্যাখ্যার জন্য ধরে নেওয়া মান। এটি কোনো নির্দিষ্ট PC-তে পুনরুৎপাদন বা উন্নতি মেপে দেখার রিপোর্ট নয়। নিবন্ধের শেষাংশের ধাপগুলো পাঠক নিজের পরিবেশে করে যাচাই করার জন্য।

কার্যপ্রণালী পরের “অডিও প্লেব্যাক বাফার” অংশ থেকে ক্রমানুসারে পড়া যায়। ড্রপআউট অনুসন্ধানের ধাপগুলো “পুনরুৎপাদনের শর্ত তুলনা” ও “WPR দিয়ে ড্রপআউট রেকর্ড” অংশে আছে।

চিত্রে, টানা রেখা সবসময় সত্য এমন সম্পর্ককে এবং ভাঙা রেখা শর্তসাপেক্ষ সম্পর্ককে নির্দেশ করে (শর্তগুলো বিস্তারিত পাতায় প্রতিটি সম্পর্কের ব্যাখ্যায় আছে)। সম্পর্কের সম্পূর্ণ তালিকা (মোট 5, প্রমাণ ও নিশ্চয়তার মাত্রাসহ) এবং প্রধান ধারণাগুলোর সংজ্ঞা জ্ঞান মানচিত্রের বিস্তারিত পাতায় সংগ্রহ করা আছে (জাপানি ভাষায়)। তথ্য: JSON-LD / Turtle

অডিও প্লেব্যাক বাফার

শুধু মিউজিক ফাইল সেভ করে রাখলেই স্পিকার বাজে না। অ্যাপ অডিও ডেটা প্রস্তুত করে, আর Windows ও ড্রাইভারের মাধ্যমে তা আউটপুট ডিভাইসে পৌঁছে দেয়। অডিও প্লেব্যাক বাফার হলো এমন একটি জায়গা, যেখানে এরপর বাজবে এমন ডেটা সাময়িকভাবে জমা থাকে। ডিভাইস যখন বর্তমান ডেটা বাজাচ্ছে, তখনই সরবরাহকারী দিক পরের ডেটা প্রস্তুত করে পূরণ করে। Rendering a Stream

flowchart TB
    accTitle: একটু আগের অডিও জমিয়ে তারপর বাজানো
    accDescr: প্রস্তুত অডিও ডেটা বাফারে পূরণ করা হয়, আর ডিভাইসের দিকে প্লেব্যাক চলার সময় পরের ডেটা প্রস্তুত করা হয়, এই প্রবাহ দেখানো হয়েছে।
    A["পরের অডিও প্রস্তুত"] --> B["বাফারে পূরণ"]
    B --> C["জমা অডিও বাজানো"]
    C -.->|"শেষ হওয়ার আগে"| A

চিত্র 1: প্লেব্যাক চালু রাখতে হলে, অডিও খরচ করা দিকের সাথে পূরণকে তাল মিলিয়ে চলতে হবে।

চিত্র 1 শুধু পূরণ ও খরচের সম্পর্ক দেখানো একটি ধারণাগত চিত্র। আসল অডিও পথে থাকা একাধিক বাফারকে বাস্তবে একটিই জায়গা হিসেবে ধরে নেওয়ার চিত্র এটি নয়। Low Latency Audio

বাফারের কাজ হলো অডিও প্রস্তুতকারী দিক আর ব্যবহারকারী দিকের মধ্যে ছোট সময়ের ব্যবধান শোষণ করে প্লেব্যাক নিরবচ্ছিন্ন রাখা। তবে বাফারের ধারণক্ষমতা আর এই মুহূর্তে এতে থাকা না-বাজানো ডেটার পরিমাণ আলাদা বিষয়। “10 মিলিসেকেন্ডের ধারণক্ষমতা আছে” মানে সবসময় 10 মিলিসেকেন্ডের ডেটা বাকি থাকে, তা নয়। Rendering a Stream

এখানে, চলমান ডেটা শেষ হওয়ার আগে দরকারি পরের ডেটা পৌঁছে দেওয়ার সময়গত বাধ্যবাধকতাকে পূরণের ডেডলাইন বলা হচ্ছে। অডিও প্রসেসিংয়ে দরকার “বাজানোর সময়ের মধ্যে প্রস্তুত হয়েছে”। “শেষ পর্যন্ত হিসাব হয়ে গেছে” যথেষ্ট নয়। সরবরাহ সময়মতো না পৌঁছানোয় বাজানোর ডেটা ফুরিয়ে যাওয়ার অবস্থাকে আন্ডাররান বলে, যার ফলে অডিও ড্রপআউট বা ক্লিকের শব্দ হয়। দেরিতে ডেটা পৌঁছালেও, ইতিমধ্যে শোনা বিরতি পরে আর পূরণ করা যায় না। Exclusive-Mode Streams

অডিও ডেটার পথ

সাধারণ শেয়ার্ড মোডে, প্লেব্যাক অ্যাপের প্রস্তুত করা ডেটা Windows-এর অডিও ইঞ্জিন গ্রহণ করে, একাধিক শব্দ মিশিয়ে বা ইফেক্ট প্রয়োগ করে, তারপর ড্রাইভার ও আউটপুট ডিভাইসে পাঠায়। প্লেব্যাক অ্যাপ অডিও সোর্স পড়া ও আউটপুট গন্তব্যে সরবরাহ, দুটোতেই জড়িত থাকে; আর ড্রাইভার ও আউটপুট ডিভাইস ডেটা ডিভাইসের দিকে বয়ে নিয়ে গিয়ে বাজায়। Low Latency Audio

flowchart TB
    accTitle: শেয়ার্ড মোডে অডিও ডেটার পথ
    accDescr: প্লেব্যাক অ্যাপের প্রস্তুত ডেটায় অডিও ইঞ্জিন মিক্সিং ও ইফেক্ট প্রসেস করে ড্রাইভারে পাঠায়, আর আউটপুট ডিভাইস তা বাজায়।
    A["প্লেব্যাক অ্যাপ: ডেটা প্রস্তুত"] --> E["অডিও ইঞ্জিন: মিক্সিং, ইফেক্ট"]
    E --> D["ড্রাইভার: ডিভাইসে পৌঁছানো"]
    D --> O["আউটপুট ডিভাইস: বাজানো"]

চিত্র 2: এটি শেয়ার্ড মোডের উদাহরণ। মাঝের প্রসেসিং ও বাফার API ও ডিভাইসভেদে বদলায়।

ডিভাইসের দিকেও প্রসেসিং বা বাফার থাকতে পারে, তাই শুধু অ্যাপের দিকের বাফার দিয়ে মোট লেটেন্সি নির্ধারিত হয় না। এই ব্যাখ্যা শেয়ার্ড মোডের পথ ধরে নিয়ে দেওয়া; এর মানে এই নয় যে সব API-তে একই প্রসেসিং হয়। Low Latency Audio

10 মিলিসেকেন্ড বাকি থাকতে পূরণ

ধরা যাক, বাফারে এখন আর 10 মিলিসেকেন্ডের না-বাজানো ডেটা বাকি আছে। পরের পূরণ 8 মিলিসেকেন্ড পরে হলে ডেটা থাকতে থাকতেই প্লেব্যাক জোড়া লাগে; কিন্তু 12 মিলিসেকেন্ড পর পর্যন্ত পূরণ করা না গেলে, এই সরলীকৃত উদাহরণে 10 মিলিসেকেন্ডের মাথায় ডেটা ফুরিয়ে যায়।

flowchart TB
    accTitle: একই 10 মিলিসেকেন্ড বাকি থাকলেও পূরণের সময়ে ফল বদলায়
    accDescr: ব্যাখ্যার জন্য ধরা 10 মিলিসেকেন্ডের অবশিষ্ট প্লেব্যাক ডেটায়, 8 মিলিসেকেন্ড পরের পূরণ সময়মতো হয় আর 12 মিলিসেকেন্ড পরের পূরণ ডেটা ফুরানোর পরে আসে, তা দেখানো হয়েছে।
    A["10 মিলিসেকেন্ড বাকি"] --> B{"পরের পূরণ"}
    B -->|"8 মিলিসেকেন্ড পরে"| C["জোড়া লাগে"]
    B -->|"12 মিলিসেকেন্ড পরে"| D["10 মিলিসেকেন্ডে ফুরায়"]

চিত্র 3: সময়কে সরল করা উদাহরণ। পূরণ হয়েছে কি না শুধু তা নয়, কখন পূরণ হয়েছে সেটাও গুরুত্বপূর্ণ।

CPU ব্যবহার ও পূরণে দেরি

CPU ব্যবহার দেখায় নির্দিষ্ট সময়ের মধ্যে CPU কতটা ব্যস্ত ছিল। অডিও প্রসেসিং দরকারি মুহূর্তে চলতে পেরেছিল কি না, সেটা আলাদা বিষয়। 1 সেকেন্ডের বেশিরভাগ সময় CPU ফাঁকা থাকলেও, একবার 12 মিলিসেকেন্ড ধরে পূরণ করা না গেলে, ওই একবারের দেরিতেই অডিও কেটে যেতে পারে। পরে বাকি থাকা প্রসেসিং ক্ষমতা দিয়ে পেরিয়ে যাওয়া প্লেব্যাক সময় ফিরিয়ে আনা যায় না। CPU Analysis

flowchart TB
    accTitle: গড় ফাঁকা ক্ষমতা আর একবারের পূরণ-দেরি
    accDescr: 1 সেকেন্ডের বেশিরভাগ সময় CPU ফাঁকা থাকলেও, একবার 12 মিলিসেকেন্ড ধরে পূরণ করা না গেলে ওই একবারের দেরিতে অডিও কেটে যেতে পারে।
    A["1 সেকেন্ডের বেশিরভাগ CPU ফাঁকা"] --> B["একবার 12 মিলিসেকেন্ড পূরণ হয় না"]
    B --> C["ওই একবারেই অডিও কাটে"]

চিত্র 4: গড়ে ফাঁকা ক্ষমতা থাকলেও পেরিয়ে যাওয়া প্লেব্যাক সময় ফেরত আসে না।

ডেডলাইনের মার্জিন শুধু হিসাবের সময়েই কমে না। প্রসেসিং শুরু হওয়া পর্যন্ত অপেক্ষা আর দরকারি ডেটা পৌঁছানো পর্যন্ত অপেক্ষাও এর মধ্যে পড়ে। তাই অনুসন্ধানের প্রশ্নও শুধু “CPU কত % ছিল”-এ আটকে না রেখে “অডিও কাটার মুহূর্তে পরের অডিও কীসের অপেক্ষায় ছিল“-এ নিয়ে যান।

ডেটা ও লকের অপেক্ষা

ধরা যাক, অডিও ডেটা প্রস্তুতকারী প্রসেসিং ফাইল পড়া শেষ হওয়ার অপেক্ষায় আছে। অ্যাপের ভেতরে অন্য কোনো প্রসেসিংয়ের হাতে থাকা লকের অপেক্ষাতেও একই কথা। অপেক্ষারত প্রসেসিং নিজে খুব বেশি CPU ব্যবহার করে না, কিন্তু ডিভাইসের দিকে প্লেব্যাক চলতে থাকে আর বাকি অডিও কমতে থাকে। Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: CPU ব্যবহার না করা অপেক্ষার সময়েও প্লেব্যাক এগোয়
    accDescr: অডিও প্রসেসিং যখন ডেটা বা লকের অপেক্ষায় থাকে, তখন সেটি CPU ব্যবহার করে না, কিন্তু প্লেব্যাক এগোয় ও অবশিষ্ট কমে; পূরণে দেরি হলে বাফার ফুরিয়ে যেতে পারে।
    A["অডিও প্রসেসিং ডেটার অপেক্ষায়"] --> B["সেটি CPU ব্যবহার করে না"]
    B --> C["এর মধ্যেও প্লেব্যাক এগোয়"]
    C --> D["পূরণে দেরি হলে ডেটা ফুরায়"]

চিত্র 5: CPU ব্যবহার না করা আর দরকারি কাজ শেষ হওয়া, দুটো আলাদা কথা।

DPC/ISR ও অডিও থ্রেড

ISR হলো ডিভাইস থেকে আসা ইন্টারাপ্ট সামলানোর রুটিন। DPC হলো ইন্টারাপ্ট হ্যান্ডলিং ছোট রাখতে বাকি কাজ পরে করার জন্য সরিয়ে রাখার ব্যবস্থা। সাধারণ DPC একই লজিক্যাল CPU-তে সাধারণ থ্রেডের আগে চলে, আর সাধারণ DPC বা ISR চলার সময় সেই লজিক্যাল CPU-তে সাধারণ থ্রেড চলতে পারে না। Introduction to DPCs, CPU Analysis

পুরো CPU-তে ফাঁকা ক্ষমতা থাকলেও, অডিও প্রসেসিংয়ের দরকারি CPU-তে এগুলো দীর্ঘ হলে বা ঘনঘন ঘটলে সরবরাহে দেরি হতে পারে। Microsoft-এর অডিও ও ভিডিও পারফরম্যান্স বিশ্লেষণের নথিতে নেটওয়ার্ক, স্টোরেজ, গ্রাফিক্স ইত্যাদির ড্রাইভারের দীর্ঘ DPC/ISR-কেও অডিও ড্রপআউটের সম্ভাব্য কারণ হিসেবে উল্লেখ করা হয়েছে। শুধু শব্দ বাজানো ডিভাইস পরীক্ষা করলেই যথেষ্ট, তা না-ও হতে পারে। Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: যখন ডিভাইসের প্রতিক্রিয়া অডিওর এক্সিকিউশন দেরি করায়
    accDescr: অডিও প্রসেসিংয়ের দরকারি CPU-তে সাধারণ DPC বা ISR দীর্ঘ হলে থ্রেডের এক্সিকিউশন পিছিয়ে যায় এবং পূরণের ডেডলাইনে প্রভাব পড়তে পারে।
    A["একই CPU-তে DPC/ISR"] -->|"দীর্ঘ হলে"| B["অডিওর এক্সিকিউশন অপেক্ষায় থাকে"]
    B --> C["পরের অডিও পূরণে দেরি"]
    C --> D["অবশিষ্ট ফুরালে ড্রপআউট"]

চিত্র 6: শব্দ বাজানো ডিভাইস ছাড়া অন্য প্রসেসিংও কখনো কখনো পরোক্ষভাবে অডিও পূরণে প্রভাব ফেলতে পারে।

“DPC এত মাইক্রোসেকেন্ডের কম হলে যেকোনো PC-তে অডিও কাটবে না” এমন কোনো সাধারণ সীমারেখা টানা যায় না। পারফরম্যান্স মূল্যায়ন নথির সতর্কতা-মান সেই মূল্যায়নের শর্তে প্রযোজ্য মান; আসল পূরণের ডেডলাইন ও বাফারের মার্জিন থেকে বিচ্ছিন্ন করে আমরা সেগুলোকে নিরাপত্তার মানদণ্ড হিসেবে ধরি না। Results for the Streaming Media Performance Assessment

বাফারের পরিমাণ ও প্লেব্যাক লেটেন্সি

একই শর্তে আগে থেকে জমানো অডিও বাড়ালে সাময়িক পূরণ-দেরি শোষণ করা সহজ হয়, কিন্তু নতুন তৈরি অডিওকে আগে থেকে জমা অডিওর পেছনে অপেক্ষা করতে হয়। শুধু গান শোনার জন্য এই অপেক্ষা মেনে নেওয়া গেলেও, মিউজিক্যাল কি-বোর্ড বাজানোর সময় বা মাইকের কণ্ঠ প্রসেস করে নিজে শোনার সময় অ্যাকশন আর শব্দের মধ্যে ব্যবধান অস্বস্তিকর হয়ে ওঠে। Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: বাফারের মার্জিন আর প্রতিক্রিয়ায় দেরি
    accDescr: আগে থেকে জমানো অডিও বাড়ালে সাময়িক পূরণ-দেরি শোষণ করা সহজ হয়, কিন্তু নতুন অডিও বাজা পর্যন্ত অপেক্ষার সময়ও বাড়ে।
    A["আগে জমানো অডিও বাড়ানো"] --> B["পূরণ-দেরি শোষণ সহজ"]
    B -->|"বিনিময়ে"| C["নতুন অডিও পেছনে অপেক্ষা করে"]
    C --> D["অ্যাকশন থেকে শব্দে দেরি"]

চিত্র 7: বাফার বাড়ানো মানে প্রতিক্রিয়ার গতির বিনিময়ে মার্জিন তৈরি করার একটি সমন্বয়।

“যত ছোট তত ভালো পারফরম্যান্স” যেমন নয়, “যত বড় তত সঠিক”-ও নয়। দরকারি প্রতিক্রিয়ার গতি বজায় রেখে, অডিও না কাটার মতো মার্জিন রাখুন।

বাফার বাড়ানোর সমন্বয় সাময়িক সরবরাহ-দেরির জন্য মার্জিন তৈরি করে। গড় সরবরাহই যদি খরচের সাথে তাল মেলাতে না পারে, তাহলে সীমিত বাফার বাড়ালে শুধু ফুরিয়ে যাওয়া পর্যন্ত সময় দীর্ঘ হয়, আর ডিভাইস বিচ্ছিন্ন হওয়ার সমস্যাও মেটে না। এক্সক্লুসিভ মোড ব্যবহার করলেই সব সমাধান হবে, এমন সুপারিশও এটি নয়। Exclusive-Mode Streams

48kHz-এ 480 ফ্রেমের অডিও

PCM ফ্রেম হলো একই মুহূর্তে বাজানো সব চ্যানেলের স্যাম্পল একসাথে নিয়ে গঠিত একক। স্টেরিও বলে সময় হিসাবের জন্য ফ্রেম সংখ্যা দ্বিগুণ করতে হয়, তা নয়। ফ্রেম সংখ্যা যে দৈর্ঘ্যের অডিও বোঝায় তা “ফ্রেম সংখ্যা ÷ স্যাম্পল রেট” দিয়ে বের হয়; 48kHz-এ 480 ফ্রেম হলে 480 ÷ 48000 সেকেন্ড, অর্থাৎ 10 মিলিসেকেন্ড। 48kHz রেখে ফ্রেম সংখ্যা বাড়ালে জমা রাখা যায় এমন অডিওর সময়ও বাড়ে। Rendering a Stream

এই সময় কি-বোর্ডে চাপ দেওয়া থেকে শব্দ শোনা পর্যন্ত মোট লেটেন্সি থেকে আলাদা, কারণ তাতে অ্যাপ, ড্রাইভার, ডিভাইস এবং অন্যান্য বাফার ও প্রসেসিংয়ের সময়ও যোগ হয়। DAW-এর সেটিং মানও একক ও কোন বাফারের কথা বলা হচ্ছে তা দেখে তবেই পড়ুন। Low Latency Audio

flowchart TB
    accTitle: ফ্রেম সংখ্যা থেকে পাওয়া সময় ও মোট লেটেন্সি
    accDescr: 480 ফ্রেমকে 48000 দিয়ে ভাগ করে পাওয়া 10 মিলিসেকেন্ড হলো বাফারের বোঝানো সময়; এর সাথে অ্যাপ, ড্রাইভার, ডিভাইস ইত্যাদির প্রসেসিং যোগ হয়ে কি-বোর্ড থেকে শব্দ পর্যন্ত মোট লেটেন্সি হয়।
    A["480 ÷ 48000"] --> B["বাফারের 10 মিলিসেকেন্ড"]
    B -->|"অন্য প্রসেসিংও যোগ হয়"| C["কি-বোর্ড থেকে শব্দ পর্যন্ত মোট লেটেন্সি"]

চিত্র 8: ফ্রেম সংখ্যা থেকে পাওয়া সময় মোট লেটেন্সির একটি অংশ মাত্র।

পুনরুৎপাদনের শর্ত তুলনা

প্রথমে কোন সমন্বয়ে সমস্যা পুনরুৎপাদন হয় তার পরিসর ছোট করুন, আর দরকার হলেই কেবল বিস্তারিত রেকর্ডিংয়ে যান। নিচের ধাপগুলো কারণ যাচাইয়ের জন্য; সব সেটিং পরিবর্তন একসাথে প্রয়োগ করার মতো সমাধানের তালিকা নয়।

কাজ সেভ করুন, চলমান লাইভ মিটিং বা রেকর্ডিং শেষ করুন, তারপর কানে চাপ পড়ে না এমন ভলিউমে পরীক্ষা করুন। আগের আউটপুট গন্তব্য, অডিও এনহ্যান্সমেন্ট, বাফারের মান ইত্যাদি লিখে রাখুন, যাতে আগের অবস্থায় ফেরানো যায়। যে সেটিং দেওয়া নেই তা বাদ দিন; সেটিং দেখানোর জন্য রেজিস্ট্রি ইত্যাদি বদলাবেন না।

1. একই ছোট অডিও সোর্স ও পর্যবেক্ষণের সময় ঠিক করুন, এবং আগের শর্তে পুনরুৎপাদন হয় কি না যাচাই করুন।

   Windows-এর সংস্করণ, অ্যাপের নাম ও সংস্করণ, আউটপুট ডিভাইস, সংযোগের ধরন ও ড্রাইভারের সংস্করণ রেকর্ড করুন। ড্রপআউটের সময়, তখনকার অপারেশন ও কতবার হয়েছে, তাও লিখে রাখুন। আগের শর্তে পুনরুৎপাদন না হলে একে উন্নতি ধরবেন না; পুনরুৎপাদনের শর্ত খোঁজায় ফিরে যান।

2. নিচের টেবিল থেকে একটি তুলনা বেছে নিন, এবং শুধু সেই শর্তটি বদলে বাজান।

   তুলনার শর্ত	যা দেখবেন
   নিজের কাছে সেভ করা অডিও সোর্স বনাম নেটওয়ার্কের মাধ্যমে প্লেব্যাক	শুধু নেটওয়ার্কের মাধ্যমে বাজালেই কি হয়? বিষয়বস্তু এক হলেও ফরম্যাট বা প্রসেসিং পথ আলাদা হলে তাও রেকর্ড করুন।
   একই অডিও সোর্স অন্য অ্যাপে বাজানো	নির্দিষ্ট কোনো অ্যাপে বেশি হয় কি?
   Bluetooth ইত্যাদি আউটপুট বনাম বিল্ট-ইন বা তারযুক্ত আউটপুট	নির্দিষ্ট কোনো আউটপুট পথে বেশি হয় কি?
   অডিও এনহ্যান্সমেন্ট চালু বনাম বন্ধ	ইফেক্ট প্রসেসিংয়ের সাথে সমন্বয়ে বদলায় কি?
   DAW ইত্যাদিতে বর্তমান বাফার বনাম এক ধাপ বড় মান	আগে জমানোর মার্জিন বাড়ালে বদলায় কি? অ্যাকশন থেকে শব্দ পর্যন্ত দেরিও গ্রহণযোগ্য কি?

3. অডিও এনহ্যান্সমেন্ট তুলনা করলে, সংশ্লিষ্ট আউটপুটে সেটিংটি সাময়িকভাবে বন্ধ করুন।

   Windows-এর “Settings” → “System” → “Sound”-এ গিয়ে সংশ্লিষ্ট আউটপুট বেছে নিন, এবং যেখানে পাওয়া যায় সেখানে “Audio enhancements” বন্ধ করুন। প্রদর্শন ভিন্ন হলে বা অপশনটি না থাকলে, সেই সংস্করণ বা ডিভাইসের নির্দেশনা দেখুন। Fix distorted or crackling audio in Windows

4. বদলানো সেটিং আগের অবস্থায় ফিরিয়ে, একই অডিও সোর্স ও পর্যবেক্ষণের সময়ে আবার পরীক্ষা করুন।

   “আগের শর্ত”, “একটি বদলানো শর্ত” ও “আগের অবস্থায় ফেরানো শর্ত”-এর ফলাফল পাশাপাশি রাখুন। যে পরিবর্তনে কোনো প্রভাব নেই, তা আগের অবস্থায় ফিরিয়ে তারপর অন্য তুলনায় যান। সেটিংয়ের সমন্বয় বদলাতে থাকলে কোনটি কাজ করেছে তা বোঝা যায় না।

5. ড্রাইভার বদলে দেখতে চাইলে, আগে অফিসিয়াল বিতরণ ও পুনরুদ্ধারের উপায় নিশ্চিত করে তারপর করুন।

   Windows Update বা ডিভাইস নির্মাতার অফিসিয়াল বিতরণ ব্যবহার করুন, এবং পরিবর্তনের আগে ও পরের সংস্করণ ও সেটিং রেকর্ড করুন। আগের অবস্থায় ফেরানো যাবে কি না আগেই যাচাই করুন, আর প্রতিষ্ঠান-পরিচালিত PC হলে অ্যাডমিনিস্ট্রেটরের সাথে পরামর্শ করুন। আপডেটের ঠিক পরে একবার ঠিকঠাক বাজলেই সমাধান ধরবেন না; একই পুনরুৎপাদনের শর্তে যাচাই করুন। Fix distorted or crackling audio in Windows

যে ফলাফল চাই তা হলো উপসর্গ ও শর্তকে মিলিয়ে রাখা রেকর্ড, যেমন “এই অ্যাপে, এই আউটপুট ব্যবহার করলে পুনরুৎপাদন হয়”। উন্নতি আনে এমন সেটিং পাওয়া গেলেও তা কারণ নিশ্চিত হওয়া থেকে আলাদা রাখুন।

flowchart TB
    accTitle: একটি শর্ত বদলে আবার আগের অবস্থায় ফেরানোর তুলনা
    accDescr: একই অডিও সোর্সে পুনরুৎপাদন যাচাই করুন, অ্যাপ বা আউটপুটের মতো একটি শর্ত বদলান, এবং আগের অবস্থায় ফেরালে কী ফল হয় তাও রেকর্ড করুন।
    A["আগের সমন্বয়ে বাজানো"] --> B["একটি শর্ত বদলে বাজানো"]
    B --> C["আগের অবস্থায় ফিরিয়ে বাজানো"]
    C --> D["কাটার শর্ত ও সময় লিখে রাখা"]

চিত্র 9: একবার ভালো হওয়ার চেয়ে, শর্ত ও উপসর্গ বারবার মেলে কি না তা নিশ্চিত করুন।

শর্ত বদলের আগে ও পরে পুনরুৎপাদন

“উপসর্গ দমানো গেছে”, “শর্তের পরিসর ছোট করা গেছে” ও “মূল কারণ শনাক্ত করা গেছে” আলাদা আলাদা পর্যায়। যতটুকু পর্যবেক্ষণ করা গেছে, সেই অনুযায়ী সিদ্ধান্ত রেকর্ড করুন।

flowchart TB
    accTitle: শর্তের সাথে সম্পর্ক দেখানো তিনটি ফলাফল
    accDescr: আগের শর্তে পুনরুৎপাদন হলে, একটি শর্ত বদলালে উন্নতি হলে এবং ফেরালে আবার পুনরুৎপাদন হলে, তা সেই শর্তের সাথে সম্পর্কের সূত্র হয়, তবে কারণ নিশ্চিত হওয়া থেকে আলাদা রাখা হয়।
    A["আগের শর্তে পুনরুৎপাদন"] --> B["একটি বদলালে উন্নতি"]
    B --> C["ফেরালে পুনরুৎপাদন"]
    C --> D["সেই শর্তের সাথে সম্পর্কের সূত্র"]

চিত্র 10: তিনটি মিললেও, জানা যায় কেবল সম্পর্কের সূত্র পর্যন্ত।

কম CPU ব্যবহার অডিওর ডেডলাইন রক্ষার প্রমাণ নয়। একইভাবে, শুধু ড্রপআউট হয়েছে বলেই পূরণ-দেরিই মূল কারণ ছিল, তাও বলা যায় না। অডিও সোর্স, অ্যাপের প্রসেসিং, ইফেক্ট, আউটপুট পথ ইত্যাদি তুলনা করুন, এবং যতটুকু পর্যবেক্ষণ করা গেছে তার ভিত্তিতে বিচার করুন। Fix distorted or crackling audio in Windows

সাময়িক সমাধান গ্রহণ করলে আগের সেটিং, কী বদলানো হয়েছে, পর্যবেক্ষণের সময়, সমস্যা আবার হয়েছে কি না এবং কতটা লেটেন্সি গ্রহণযোগ্য, তা লিখে রাখুন। মূল কারণ এখনও নিশ্চিত না হলে সে কথাও রেকর্ড করুন।

WPR দিয়ে ড্রপআউট রেকর্ড

শুধু শর্ত তুলনা করে পরিসর ছোট না হলে, অথবা ড্রাইভারের দিকের প্রসেসিং অনুসন্ধান করতে চাইলে এটি করুন। WPR রেকর্ডিংয়ের জন্য, আর WPA সেভ করা টাইমলাইন বিশ্লেষণের জন্য ব্যবহৃত টুল। Windows Performance Toolkit, রেকর্ডিংয়ের জন্য দরকারি অনুমতি ও ETL সেভ করার জায়গা প্রস্তুত রাখুন। প্রতিষ্ঠান-পরিচালিত PC-তে টুল ইনস্টল করে রেকর্ড করতে হলে অ্যাডমিনিস্ট্রেটরকে অনুরোধ করুন। প্রদর্শিত নাম ও ব্যবহারযোগ্য প্রোফাইল ইনস্টল করা সংস্করণেই যাচাই করুন। Windows Performance Recorder

ETL-এ প্রক্রিয়ার নাম, ফাইল পথ ইত্যাদি থাকতে পারে। রেকর্ড করার আগে প্রতিষ্ঠানের নিয়ম ও কার সাথে শেয়ার করবেন তা নিশ্চিত করুন, আর কোনো পাবলিক জায়গায় সরাসরি সংযুক্ত করবেন না। অন্য কোনো রেকর্ডিং সেশন চললে নিজে থেকে থামাবেন না; দায়িত্বপ্রাপ্ত ব্যক্তির কাছে জেনে নিন। WPR How-to Topics

1. WPR-এ “More Options” খুলুন, এবং উদ্দেশ্য অনুযায়ী রেকর্ডিং প্রোফাইল বেছে নিন।

   বিল্ট-ইন প্রোফাইলের মধ্যে “Audio glitches” ও “CPU usage” আছে। অডিওর বিচ্ছিন্নতা ও CPU-এর কার্যকলাপ দেখা যায় এমন সেটিং বেছে নিন। ব্যবহারযোগ্য প্রোফাইল, প্রদর্শিত নাম ও কী সংগ্রহ হয় তা ইনস্টল করা সংস্করণে যাচাই করুন, আর সব ধরন দীর্ঘ সময় রেকর্ড করার সেটিং করবেন না। Built-in Recording Profiles

2. ড্রপআউট পুনরুৎপাদনের আগেই রেকর্ডিং শুরু করুন।

   বিদ্যমান রেকর্ডিং থামানোর নিশ্চিতকরণ এলে এগোবেন না; শুরু বাতিল করে দায়িত্বপ্রাপ্ত ব্যক্তির কাছে জেনে নিন। রেকর্ডিং ছাড়া অবস্থার সাথে শর্ত মিলিয়ে রাখুন, আর রেকর্ডিংয়ের নিজস্ব লোডে উপসর্গ বদলে যেতে পারে, সেই সম্ভাবনাও মাথায় রাখুন। WPR How-to Topics

3. তুলনায় পাওয়া শর্তে বাজান, এবং কাটার সময় ও অপারেশন লিখে রাখুন।

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

4. পুনরুৎপাদনের পর “Save” দিয়ে রেকর্ডিং শেষ করুন এবং ETL ফাইল সেভ করুন।

   “Cancel” করলে সেভ হয় না। সেভের জায়গা, পুনরুৎপাদনের শর্ত, রেকর্ড হয়েছে কি না এবং ইভেন্ট হারানোর সতর্কবার্তা এসেছে কি না, তা লিখে রাখুন। ইভেন্ট হারানো রেকর্ডে না-দেখা অংশকে স্বাভাবিক বলে বিচার করবেন না। WPR How-to Topics

ETL ফাইল আর ড্রপআউটের সময়, অপারেশন ও শর্তের নোট হাতে থাকলে WPA-তে মিলিয়ে দেখার প্রস্তুতি সম্পন্ন। শুধু রেকর্ড সেভ হয়েছে বলেই দরকারি ইভেন্ট ধরা পড়েছে, তা নিশ্চিত নয়। বিষয়বস্তু পরের “ড্রপআউটের আগে-পরে এক্সিকিউশন ও অপেক্ষা” অংশে যাচাই করুন।

flowchart TB
    accTitle: ড্রপআউটসহ ছোট একটি রেকর্ড নেওয়া
    accDescr: WPR-এ রেকর্ডিং শুরু করে, উপসর্গ পুনরুৎপাদন করে সময় লিখে রাখুন, তারপর থামিয়ে সেভ করা রেকর্ড WPA-তে পরীক্ষা করুন।
    A["WPR-এ রেকর্ডিং শুরু"] --> B["একই শর্তে ড্রপআউট পুনরুৎপাদন"]
    B --> C["সময় ও অপারেশন লিখে সেভ"]
    C --> D["WPA-তে আগে-পরের অংশ জুম"]

চিত্র 11: উপসর্গ শেষ হওয়ার পরে দেখা CPU ব্যবহার যথেষ্ট নয়; উপসর্গ ঘটার অংশের রেকর্ড দরকার।

ড্রপআউটের আগে-পরে এক্সিকিউশন ও অপেক্ষা

সেভ করা ETL ও পুনরুৎপাদনের সময়ের নোট প্রস্তুত রাখুন। নিচের ধাপগুলো WPA-তে অনুসন্ধানের সূচনাবিন্দু। স্ট্যাক ও সিম্বলসহ বিস্তারিত বিশ্লেষণ দরকার হলে, রেকর্ডের ব্যবহারে সতর্ক থেকে অ্যাডমিনিস্ট্রেটর বা ডেভেলপারকে অনুরোধ করুন।

1. ETL WPA-তে খুলুন, এবং ধরা পড়া অডিও ইভেন্ট ও পুনরুৎপাদনের সময়ের ভিত্তিতে ড্রপআউটের আগে-পরের অংশ জুম করুন।

   তুলনার জন্য উপসর্গহীন অংশও রাখুন। শুধু সর্বোচ্চ মানের র‍্যাঙ্কিং দেখবেন না; একই সময়-পরিসরে মিলিয়ে তুলনা করুন।

2. একই পরিসরে “DPC/ISR” ও “CPU Usage (Precise)” দেখুন।

   দরকারি ডেটা না থাকলে, প্রোফাইলটি তা ধরতে পারে কি না যাচাই করে WPR রেকর্ডিংয়ে ফিরে যান। রেকর্ড না থাকা আর সমস্যা না থাকা আলাদা কথা। CPU Analysis, Built-in Recording Profiles

3. অডিও-সংশ্লিষ্ট থ্রেডটি চলার জন্য প্রস্তুত থেকেও পালার অপেক্ষায় ছিল, নাকি ডেটা ইত্যাদির অপেক্ষায় ছিল, তা আলাদা করুন।

   প্রথম ক্ষেত্রে, সংশ্লিষ্ট লজিক্যাল CPU-তে DPC/ISR ইত্যাদি দীর্ঘ সময় চলছিল কি না মিলিয়ে দেখুন। দ্বিতীয় ক্ষেত্রে, কী অপেক্ষা শেষ করেছিল তা ধরা পড়া ইভেন্ট বা স্ট্যাক দিয়ে খুঁজুন। চলমান থ্রেডও ইন্টারাপ্টে থেমে যেতে পারে, তাই শুধু Ready সময়ে সীমাবদ্ধ না থেকে DPC/ISR-এর অংশও ওভারলে করে দেখুন। CPU Analysis

4. ড্রপআউটের সাথে সময়ের মিল, সংশ্লিষ্ট CPU এবং শর্ত বদলের ফলাফল একসাথে রেকর্ড করুন।

   দীর্ঘ DPC/ISR-এর শুধু মডিউলের নাম দেখে কোনো নির্দিষ্ট ডিভাইস বা ড্রাইভারকে কারণ বলে নিশ্চিত করবেন না। হতে পারে আপনি অন্য সময়ের বড় মান দেখছেন, বা এমন কোনো সাধারণ অংশ দেখছেন যার মধ্য দিয়ে একাধিক ডিভাইস যায়।

flowchart TB
    accTitle: ড্রপআউটের অংশে অপেক্ষার ধরন পরীক্ষা
    accDescr: ড্রপআউটের আগে-পরের অংশ জুম করে অডিও থ্রেডের অবস্থা দেখুন। চলার জন্য প্রস্তুত থেকে পালার অপেক্ষা হলে একই CPU-এর DPC বা ISR-এর সাথে মেলান, আর ডেটা ইত্যাদির অপেক্ষা হলে অপেক্ষা শেষ করা প্রসেসিং খুঁজুন।
    A["ড্রপআউটের আগে-পরে জুম"] --> B{"থ্রেডের অবস্থা"}
    B -->|"পালার অপেক্ষা"| C["DPC/ISR"]
    B -->|"ডেটার অপেক্ষা"| D["অপেক্ষা শেষ করা প্রসেসিং"]

চিত্র 12: শুধু সর্বোচ্চ মান তুলে আনবেন না; অডিও প্রসেসিং দরকার ছিল এমন অংশের সাথে মিলিয়ে পড়ুন।

শনাক্ত করা না গেলে, অনিশ্চিত হিসেবে অনুসন্ধান হস্তান্তর করুন। সাথে দিন: OS, অ্যাপ, ডিভাইস ও ড্রাইভারের সংস্করণ, পুনরুৎপাদনের ধাপ, পরিবর্তনের আগে ও পরের ফলাফল, ঘটনার সময়, সংগ্রহের প্রোফাইল এবং ইভেন্ট হারানোর সতর্কবার্তা ছিল কি না। ETL প্রতিষ্ঠানের নিয়ম মেনে শুধু অনুসন্ধানের দায়িত্বে থাকা ব্যক্তির সাথে শেয়ার করুন।

অডিও অ্যাপে আগাম ডেটা লোড

নিজে অডিও অ্যাপ তৈরি করলে, ডিজাইন এমন রাখুন যাতে পরের বাফার ভরার প্রসেসিং প্রতিবার ডেডলাইনের মধ্যে শেষ হয়। WASAPI-তে বাফার প্রসেস করার উপযুক্ত সময় ইভেন্টের মাধ্যমে জানার একটি উপায় আছে। Exclusive-Mode Streams

MMCSS হলো সময়-সীমাবদ্ধ মাল্টিমিডিয়া প্রসেসিংয়ের থ্রেডে CPU রিসোর্স বরাদ্দ করার ব্যবস্থা। ডিস্ক থেকে ডেটা আগে থেকে প্রস্তুত করা বা লকের অপেক্ষা দূর করার মতো কোনো ফিচার এতে নেই। MMCSS-এর বরাদ্দ ব্যবহার করলেও, ডেটা প্রস্তুত করা ও অপেক্ষা কমানোর ডিজাইন আলাদাভাবে দরকার। Multimedia Class Scheduler Service

flowchart TB
    accTitle: MMCSS যা সামলায়
    accDescr: MMCSS সময়-সীমাবদ্ধ প্রসেসিংয়ের থ্রেডে CPU রিসোর্স বরাদ্দ করে, কিন্তু ডেটা প্রস্তুত করা ও লকের অপেক্ষা কমানো আলাদা ডিজাইনে করা হয়।
    M["MMCSS: CPU রিসোর্স বরাদ্দ"] -.->|"আলাদাভাবে দরকার"| D["ডেটা প্রস্তুতি ও অপেক্ষা কমানো"]

চিত্র 13: CPU রিসোর্স বরাদ্দ আর ডেটা সময়মতো প্রস্তুত রাখার ডিজাইন, দুটো আলাদা কাজ।

ডিজাইনের নীতি হলো ফাইল বা নেটওয়ার্ক থেকে পড়ার প্রসেসিং আর অডিও পাঠানোর প্রসেসিং আলাদা রাখা। কতক্ষণ লাগবে আন্দাজ করা কঠিন এমন প্রস্তুতি আগেভাগে সেরে রাখুন, আর হস্তান্তরের জন্য আগে থেকে বরাদ্দ করা বাফার ব্যবহার করুন। অডিওর দিককে এমনভাবে গড়ুন যাতে UI-এর সাড়া, দীর্ঘ লক বা সিঙ্ক্রোনাস লগ লেখার জন্য অপেক্ষা করতে না হয়।

flowchart TB
    accTitle: সময় আন্দাজ করা কঠিন প্রস্তুতিকে অডিও সরবরাহ থেকে আলাদা করা
    accDescr: পড়া ইত্যাদি আগাম প্রসেসিংয়ে সেরে, প্রস্তুত ডেটা বাফারের মাধ্যমে অডিও প্রসেসিংকে দেওয়া হয়, যাতে ডেডলাইনের ঠিক আগে দীর্ঘ অপেক্ষা কমে, এমন ডিজাইন।
    A["আগাম প্রসেসিংয়ে ডেটা প্রস্তুত"] --> B["আগে বরাদ্দ করা হস্তান্তর-জায়গা"]
    B --> C["অডিও প্রসেসিং দরকারি অংশ দেয়"]
    C --> D["অডিও আউটপুটে সরবরাহ"]

চিত্র 14: সময়সাপেক্ষ কাজকে অডিও হস্তান্তরের ঠিক আগের মুহূর্ত থেকে সরিয়ে দিন।

প্রস্তুতির দিক দীর্ঘ সময় থেমে থাকলে, এই বিভাজন থাকলেও জমা ডেটা ফুরিয়ে যায়। শুধু গড় প্রসেসিং সময় নয়, দীর্ঘ প্রসেসিং বা অপেক্ষা ঘটার মুহূর্ত এবং কতবার সরবরাহ করা যায়নি, তাও অডিও প্রসেসিংয়ে ব্যাঘাত না ঘটানো উপায়ে রেকর্ড করুন। আসলে বেছে নেওয়া বাফারের পরিমাণ ও পিরিয়ড API বা ড্রাইভার থেকে যাচাই করুন; নির্দিষ্ট করা মানই হুবহু গৃহীত হয়েছে, এমন ধরে নেবেন না। Rendering a Stream, Low Latency Audio

সংখ্যার উদাহরণ ও ডিজাইনের উদাহরণ দুটোই ব্যাখ্যার জন্য; এগুলো কোনো নির্দিষ্ট ডিভাইসের জন্য সুপারিশকৃত সেটিং মান নয়, আবার যেকোনো পরিবেশে অডিও না কাটার নিশ্চয়তাও নয়।

রিয়েলটাইম অগ্রাধিকারের প্রভাব

ব্যবহারকারী পুরো প্লেয়ারকে “Realtime” অগ্রাধিকারে বদলাবেন, এটি আমরা ঢালাওভাবে সুপারিশ করি না। এতে অন্য গুরুত্বপূর্ণ প্রসেসিং বাধাগ্রস্ত হওয়ার ঝুঁকি আছে, আর সাধারণ থ্রেডের অগ্রাধিকার বাড়ালেও DPC/ISR বা ডেটা ও লকের অপেক্ষা দূর হয় না। ডেভেলপমেন্টে MMCSS-এর মতো ব্যবস্থা এবং অডিও সরবরাহে দীর্ঘ অপেক্ষা ঢুকতে না দেওয়া ডিজাইন ব্যবহার করুন। Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: রিয়েলটাইম অগ্রাধিকারে বদলালেও থেকে যাওয়া অপেক্ষা
    accDescr: প্লেয়ারকে রিয়েলটাইম অগ্রাধিকারে দিলেও সাধারণ থ্রেড একই CPU-তে DPC বা ISR-কে টপকাতে পারে না, ডেটা বা লকের অপেক্ষাও থেকে যায়, আর অন্য গুরুত্বপূর্ণ প্রসেসিং বাধাগ্রস্ত হওয়ার ঝুঁকিও আছে।
    A["প্লেয়ার রিয়েলটাইম অগ্রাধিকারে"] --> B["DPC/ISR টপকানো যায় না"]
    B --> C["ডেটা ও লকের অপেক্ষাও থাকে"]
    C --> D["অন্য প্রসেসিং বাধার ঝুঁকি"]

চিত্র 15: অগ্রাধিকার বাড়ালেও অডিও পূরণ পিছিয়ে দেওয়া অপেক্ষা থেকে যায়।

সম্পর্কিত নিবন্ধ

• Windows-এর “Processor scheduling” ও ব্যাকগ্রাউন্ড সার্ভিস সেটিং
• Windows-এ ডিস্ক 100%-এর কারণ নিরাপদে আলাদা করা
• সংযোগ দ্রুত, তবু RDP ধীর কেন?

তথ্যসূত্র

• Microsoft Learn, Rendering a Stream। প্লেব্যাক বাফারে সরবরাহ, অবশিষ্ট ডেটা, আসল বাফার সাইজ ও PCM ফ্রেমের সংজ্ঞা।
• Microsoft Learn, Exclusive-Mode Streams। বাফার সরবরাহের সময় ও অডিও গ্লিচ, লেটেন্সির সাথে ভারসাম্য, ইভেন্ট-চালিত সরবরাহ। এক্সক্লুসিভ মোডকে ঢালাওভাবে সুপারিশ করার জন্য এই সূত্র দেওয়া হয়নি।
• Microsoft Learn, Low Latency Audio। Windows-এর অডিও পথ, বাফার, ডিভাইস ও ইফেক্ট প্রসেসিংয়ের সাথে লেটেন্সির সম্পর্ক, কম লেটেন্সির ট্রেড-অফ।
• Microsoft Learn, CPU Analysis। লজিক্যাল CPU, থ্রেডের Ready/Waiting, DPC/ISR ও থ্রেড এক্সিকিউশনের সম্পর্ক, WPA-র CPU বিশ্লেষণ।
• Microsoft Learn, Introduction to DPCs। ইন্টারাপ্ট হ্যান্ডলিং ছোট রেখে বাকি কাজ DPC-তে পাঠানোর ব্যবস্থা।
• Microsoft Learn, Results for the Streaming Media Performance Assessment। দীর্ঘ ও ঘনঘন DPC/ISR, ডেটা সরবরাহের ঘাটতি ও অডিও গ্লিচ। মূল্যায়নের সতর্কতা-মানকে আমরা সব ডিভাইসের নিরাপত্তা মানদণ্ড হিসেবে সাধারণীকরণ করি না।
• Microsoft Support, Fix distorted or crackling audio in Windows। অডিও এনহ্যান্সমেন্ট, ফরম্যাট, ড্রাইভার ইত্যাদি যাচাই।
• Microsoft Learn, Windows Performance Recorder। ETW রেকর্ডিং ও WPA দিয়ে বিশ্লেষণ, Windows Performance Toolkit-এর ব্যবহার।
• Microsoft Learn, Built-in Recording Profiles। WPR-এর More Options এবং Audio glitches ও CPU usage-এর মতো বিল্ট-ইন প্রোফাইল।
• Microsoft Learn, WPR How-to Topics। রেকর্ডিং শুরু ও Save দিয়ে সংরক্ষণ, বিদ্যমান সেশনের সাথে সংঘাত, ব্যক্তিগত তথ্য ও ইভেন্ট হারানো নিয়ে সতর্কতা।
• Microsoft Learn, Multimedia Class Scheduler Service। সময়-সীমাবদ্ধ মাল্টিমিডিয়া প্রসেসিংয়ে CPU রিসোর্স বরাদ্দ।
• Microsoft Learn, Scheduling Priorities। প্রক্রিয়া ও থ্রেডের অগ্রাধিকার, এবং রিয়েলটাইম অগ্রাধিকার নিয়ে সতর্কতা।

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই বিষয়ের কাছাকাছি টপিক পৃষ্ঠা। নিবন্ধ থেকে শুরু করে সংশ্লিষ্ট সেবা ও অন্য নিবন্ধে যাওয়া যাবে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

এই নিবন্ধ নিচের সেবা পৃষ্ঠাগুলোর সঙ্গে যুক্ত। কাছের প্রবেশপথ থেকে দেখে নিন।

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

CPU ব্যবহার মাত্র 10%-এর মতো, তবু অডিও কেটে যায় কেন?

অডিওর একটি ডেডলাইন আছে: চলমান ডেটা শেষ হওয়ার আগেই পরের ডেটা পূরণ করতে হয়। পুরো CPU-এর ব্যবহার কম হলেও, সেই মুহূর্তে অডিও প্রসেসিং চলতে না পারলে বা দরকারি ডেটার অপেক্ষায় থাকলে পূরণ সময়মতো না-ও হতে পারে। সব অডিও ড্রপআউটের কারণ এটাই, তা নয়; আউটপুট ডিভাইস বা অ্যাপ বদলে তুলনা করাও দরকার।

অডিও বাফার বড় করলে কি ড্রপআউট ঠিক হয়ে যায়?

পূরণ সাময়িকভাবে দেরি হলে বড় বাফার তা শোষণ করতে পারে। তবে জমা রাখা অডিও বাজা পর্যন্ত অপেক্ষার সময়ও বাড়ে। প্রসেসিং ক্ষমতার স্থায়ী ঘাটতি বা ডিভাইস বিচ্ছিন্ন হওয়ার সমস্যা এই সেটিং দূর করে না। যেসব অ্যাপ বা ড্রাইভারে এটি বদলানো যায়, সেখানে আগের মান লিখে রেখে এক ধাপ করে তুলনা করুন।

48kHz-এ 480 ফ্রেম কত মিলিসেকেন্ডের অডিও?

480 ÷ 48000 সেকেন্ড, অর্থাৎ 10 মিলিসেকেন্ড। PCM-এর এক ফ্রেম হলো একই মুহূর্তের সব চ্যানেলের স্যাম্পল একসাথে নিয়ে গঠিত একক। এই মান হলো ওই সংখ্যক ফ্রেম যে দৈর্ঘ্যের অডিও বোঝায় তা; ডিভাইস ও অ্যাপসহ মোট লেটেন্সি নয়।

DPC বা ISR-এর এক্সিকিউশন সময় দীর্ঘ এমন ড্রাইভারই কি অডিও ড্রপআউটের অপরাধী?

সম্ভাব্য কারণ হতে পারে, কিন্তু শুধু এক্সিকিউশন সময়ের র‍্যাঙ্কিং দেখে নিশ্চিত হওয়া যায় না। যে অংশে ড্রপআউট হয়েছে, তাকে অডিও থ্রেডের অপেক্ষা এবং একই CPU-তে DPC/ISR-এর এক্সিকিউশনের সাথে মিলিয়ে দেখুন। শুধু মডিউলের নাম দেখে কোনো নির্দিষ্ট ডিভাইস বা ড্রাইভারের ত্রুটি বলে সিদ্ধান্ত নেবেন না; পুনরুৎপাদনের শর্ত বদলে পাওয়া ফলাফলও যাচাই করুন।

প্লেয়ারকে রিয়েলটাইম অগ্রাধিকারে দিলে কি উন্নতি হয়?

এটি আমরা ঢালাওভাবে সুপারিশ করি না। সাধারণ থ্রেডের অগ্রাধিকার বাড়ালেও সেটি একই CPU-তে সাধারণ DPC বা ISR-কে টপকে যেতে পারে না, আর ডেটা বা লকের অপেক্ষাও মিটে যায় না। ডেভেলপাররা MMCSS-এর মতো ব্যবস্থা ও অপেক্ষা ঢুকতে না দেওয়া ডিজাইন ব্যবহার করুন; ব্যবহারকারীরা আগে পুনরুৎপাদনের শর্ত ও আউটপুট পথ তুলনা করুন।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তকে কেন্দ্র করে কাজ করেন; বিদ্যমান সম্পদ রয়ে গেছে এমন প্রকল্পে এবং কারণ সহজে চোখে পড়ে না এমন ব্যর্থতার তদন্তে তাঁর বিশেষ শক্তি রয়েছে।