CPU usage कम है, फिर भी audio क्यों कटता है? — buffer और deadline से समझें

Music सुनते समय audio बीच-बीच में “टक्” से कट जाता है। Task Manager में CPU usage 10% के आसपास है, फिर भी सिर्फ़ audio stable नहीं रहता। ऐसे में सवाल उठता है: जब CPU के पास काफ़ी headroom है, तब भी audio क्यों कटता है?

CPU usage कम होने पर भी, अगर अगले audio data का refill deadline तक न पहुँचे, तो audio कट सकता है। वजह यह है कि buffer में बचा audio play होते-होते ही अगला data देना पड़ता है। Data या lock की wait, या ज़रूरी logical CPU पर DPC/ISR जैसी वजहों से refill का late होना, पूरे CPU को पूरी तरह इस्तेमाल किए बिना भी हो सकता है। Exclusive-Mode Streams, CPU Analysis

हालाँकि, सिर्फ़ सुनाई दिए “टक्” के आधार पर इसे underrun नहीं कहा जा सकता। Audio source, ऐप, audio effects, output device वगैरह से भी ऐसे ही symptoms आते हैं। पहले उसी audio source के साथ conditions को एक-एक करके बदलें और फिर पहले जैसा करके compare करें; अगर तब भी narrow down न हो, तो dropout से पहले और बाद का समय record करें। Fix distorted or crackling audio in Windows

यह लेख इसी सवाल को, और उसके बाद आने वाले सवालों “क्या buffer बड़ा कर देना काफ़ी है?” और “क्या compare करें और क्या record करें ताकि cause narrow down हो?” को cover करता है। यह सिर्फ़ CPU usage या सुनाई दी आवाज़ के आधार पर किसी खास failure का cause तय नहीं करता।

Scope मुख्य रूप से Windows 11 पर audio output है। Built-in, wired, USB, Bluetooth जैसे outputs को comparison में शामिल किया गया है, और music production software (DAW) के लिए उस स्थिति का comparison भी है जब ऐप या driver buffer setting देता हो। पूरे recording system का design और हर device के wireless communication का diagnosis इसमें पूरी तरह cover नहीं किया गया है।

Explanation में shared mode को basic example के रूप में लिया गया है। असली path, buffer size और processing period ऐप, API, driver और device के हिसाब से अलग होते हैं, और ऐसी कोई buffer setting screen भी नहीं है जो सभी ऐप्स में एक जैसी हो। Low Latency Audio

यहाँ दिखाए गए CPU usage, 10 ms का बचा हुआ data, refill का समय वगैरह समझाने के लिए मानी गई values हैं। यह किसी खास PC पर reproduce या improvement को measure करने की report नहीं है। लेख के दूसरे हिस्से के steps reader को अपने environment में करके जाँचने के लिए हैं।

Mechanism को अगले section “Audio playback buffer” से क्रम में पढ़ा जा सकता है। Audio dropout की जाँच के steps “Reproduce conditions compare करें” और “WPR से audio dropout record करें” में हैं।

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 5, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

Audio playback buffer

सिर्फ़ music file save कर देने से speaker नहीं बजता। ऐप audio data तैयार करता है और उसे Windows और driver के ज़रिए output device तक पहुँचाता है। Audio playback buffer वह area है जो आगे play होने वाले data को कुछ समय के लिए रखता है। जब device मौजूदा data play कर रहा होता है, उसी दौरान supply side अगला data तैयार करके refill करता है। Rendering a Stream

flowchart TB
    accTitle: थोड़ा आगे का audio जमा करके play करना
    accDescr: यह flow दिखाता है कि तैयार audio data buffer में refill होता है और device पर playback चलते समय अगला data तैयार किया जाता है।
    A["अगला audio तैयार करें"] --> B["Buffer में refill"]
    B --> C["जमा audio play"]
    C -.->|"खत्म होने से पहले"| A

चित्र 1: Playback जारी रहे, इसके लिए refill को audio consume करने वाले side के साथ बराबर चलना ज़रूरी है।

चित्र 1 सिर्फ़ refill और consumption के relation को दिखाने वाला conceptual diagram है। यह असली audio path में मौजूद कई buffers को physically एक ही area मानने वाला diagram नहीं है। Low Latency Audio

Buffer का काम है audio तैयार करने वाले side और उसे इस्तेमाल करने वाले side के बीच के छोटे time gap को absorb करना, ताकि playback लगातार चलता रहे। लेकिन buffer की capacity और उसमें इस समय मौजूद unplayed data की मात्रा अलग-अलग चीज़ें हैं। “10 ms की capacity है” का मतलब यह नहीं कि हमेशा 10 ms का data बचा रहता है। Rendering a Stream

इस लेख में, play हो रहे data के खत्म होने से पहले ज़रूरी अगला data पहुँचाने की time constraint को refill की deadline कहा गया है। Audio processing में ज़रूरी यह है कि “बजने के समय तक data तैयार हो गया”। “आख़िर में calculation पूरी हो गई” इतना काफ़ी नहीं है। Supply समय पर न पहुँचने से play करने के लिए data खत्म हो जाने वाली state को underrun कहते हैं, और इसका नतीजा audio dropout या click की आवाज़ होता है। Data देर से पहुँच भी जाए, तो जो रुकावट पहले ही सुनाई दे चुकी है उसे बाद में भरा नहीं जा सकता। Exclusive-Mode Streams

Audio data का path

सामान्य shared mode में, playback ऐप जो data तैयार करता है उसे Windows का audio engine लेता है, कई sounds को mix करता है या effects लगाता है, और फिर driver और output device को देता है। Playback ऐप audio source को पढ़ने और output destination तक supply करने, दोनों में शामिल रहता है, जबकि driver और output device data को device side तक ले जाकर play करते हैं। Low Latency Audio

flowchart TB
    accTitle: Shared mode में audio data का path
    accDescr: Playback ऐप के तैयार किए data पर audio engine mixing और effects की processing करके उसे driver को देता है, और output device उसे play करता है।
    A["Playback ऐप: data तैयार"] --> E["Audio engine: mixing, effects"]
    E --> D["Driver: device तक पहुँचाना"]
    D --> O["Output device: playback"]

चित्र 2: यह shared mode का example है। बीच की processing और buffers API और device के हिसाब से बदलते हैं।

Device side पर भी processing या buffer हो सकता है, इसलिए सिर्फ़ ऐप side का buffer पूरी latency तय नहीं करता। यह explanation shared mode के path को मानकर दी गई है; इसका मतलब यह नहीं कि हर API में यही processing होती है। Low Latency Audio

10 ms बचे होने पर refill

मान लीजिए buffer में अभी 10 ms का unplayed data बचा है। अगर अगला refill 8 ms बाद हो, तो data बचे रहते ही playback जुड़ा रहता है; लेकिन अगर 12 ms बाद तक refill न हो पाए, तो इस simplified example में 10 ms पर data खत्म हो जाता है।

flowchart TB
    accTitle: 10 ms बचे हों, तब भी refill के समय से नतीजा बदलता है
    accDescr: समझाने के लिए माने गए 10 ms के बचे playback data पर, 8 ms बाद का refill समय पर होता है, जबकि 12 ms बाद का refill data खत्म होने के बाद पहुँचता है, यह दिखाया गया है।
    A["10 ms का data बचा"] --> B{"अगला refill"}
    B -->|"8 ms बाद"| C["Playback जारी"]
    B -->|"12 ms बाद"| D["10 ms पर खत्म"]

चित्र 3: Time को simplify किया गया example है। सिर्फ़ यह नहीं कि refill हुआ या नहीं, बल्कि यह भी अहम है कि refill कब हुआ।

CPU usage और refill में देरी

CPU usage बताता है कि एक तय समय-अवधि में CPU कितना busy रहा। Audio processing ज़रूरी क्षण पर run हो पाई या नहीं, यह अलग चीज़ है। 1 सेकंड के ज़्यादातर हिस्से में CPU free हो, फिर भी अगर एक बार 12 ms तक refill न हो पाए, तो उस एक delay से ही audio कट सकता है। बाद में बची processing capacity से बीत चुके playback time को वापस नहीं लाया जा सकता। CPU Analysis

flowchart TB
    accTitle: Average headroom और एक बार का refill delay
    accDescr: 1 सेकंड के ज़्यादातर हिस्से में CPU free हो, तब भी अगर एक बार 12 ms तक refill न हो पाए, तो उस एक delay से audio कट सकता है।
    A["1 सेकंड में ज़्यादातर CPU free"] --> B["एक बार 12 ms तक refill नहीं"]
    B --> C["उसी एक बार में audio कटता है"]

चित्र 4: Average में headroom हो, तब भी बीता हुआ playback time वापस नहीं आता।

Deadline तक का margin सिर्फ़ calculation time से ही कम नहीं होता। Processing शुरू होने तक की wait और ज़रूरी data पहुँचने तक की wait भी इसमें शामिल है। इसलिए जाँच का सवाल भी सिर्फ़ “CPU कितने % था?” नहीं रहना चाहिए, बल्कि “audio कटने के क्षण अगला audio किस चीज़ की wait कर रहा था?” होना चाहिए।

Data और lock की wait

मान लीजिए audio data तैयार करने वाली processing file read पूरा होने की wait कर रही है। ऐप के अंदर किसी दूसरी processing के पास मौजूद lock की wait करने पर भी यही होता है। Wait कर रही processing ख़ुद ज़्यादा CPU इस्तेमाल नहीं करती, लेकिन device side पर playback चलता रहता है और बचा हुआ audio घटता जाता है। Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: CPU इस्तेमाल न होने वाली wait के दौरान भी playback चलता है
    accDescr: Audio processing जब data या lock की wait करती है, तब वह CPU इस्तेमाल नहीं करती, लेकिन playback आगे बढ़ता है और बचा data घटता है; refill late हो तो buffer खाली हो सकता है।
    A["Audio processing data की wait में"] --> B["वह CPU इस्तेमाल नहीं करती"]
    B --> C["इस बीच भी playback चलता है"]
    C --> D["Refill late तो data खत्म"]

चित्र 5: CPU इस्तेमाल न होना और ज़रूरी काम पूरा हो जाना, दो अलग बातें हैं।

DPC/ISR और audio thread

ISR वह routine है जो device से आए interrupt को handle करती है। DPC वह mechanism है जो interrupt handling को छोटा रखने के लिए बाकी काम को बाद के लिए टाल देता है। Normal DPC उसी logical CPU पर normal threads से पहले run होता है, और जब तक normal DPC या ISR चल रहा हो, उस logical CPU पर normal thread run नहीं हो सकता। Introduction to DPCs, CPU Analysis

पूरे CPU में headroom होने पर भी, अगर audio processing के लिए ज़रूरी CPU पर ये लंबे चलें या बार-बार आएँ, तो supply late हो सकती है। Microsoft के audio/video performance analysis document में network, storage, graphics जैसे drivers के लंबे DPC/ISR को भी audio dropout के संभावित कारणों में गिना गया है। ज़रूरी नहीं कि सिर्फ़ audio बजाने वाले device की जाँच काफ़ी हो। Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: जब device को respond करना audio execution को late करता है
    accDescr: Audio processing के लिए ज़रूरी CPU पर normal DPC या ISR लंबा चले तो thread execution late होता है और refill की deadline पर असर पड़ सकता है।
    A["उसी CPU पर DPC/ISR"] -->|"लंबा चले तो"| B["Audio execution रुका रहता है"]
    B --> C["अगले audio का refill late"]
    C --> D["Data खत्म होने पर dropout"]

चित्र 6: Audio बजाने वाले device के अलावा दूसरी processing भी कभी-कभी indirectly audio refill पर असर डाल सकती है।

“DPC इतने microseconds से कम हो तो किसी भी PC पर audio नहीं कटेगा” जैसी कोई common सीमा तय नहीं की जा सकती। Performance assessment document की warning values उसी assessment की conditions के लिए हैं; हम उन्हें असली refill deadline और buffer headroom से अलग करके safety threshold नहीं मानते। Results for the Streaming Media Performance Assessment

Buffer size और playback latency

बाकी conditions वही रखते हुए पहले से जमा किया जाने वाला audio बढ़ाएँ, तो temporary refill delay को absorb करना आसान हो जाता है; लेकिन नया बना audio पहले से जमा audio के पीछे wait करता है। सिर्फ़ music सुनने में यह wait चल जाती है, पर musical keyboard बजाते समय या mic की आवाज़ को process करके ख़ुद सुनते समय action और sound के बीच का gap खटकने लगता है। Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Buffer headroom और response में देरी
    accDescr: पहले से जमा audio बढ़ाने पर temporary refill delay absorb करना आसान होता है, लेकिन नए audio के play होने तक की wait भी बढ़ती है।
    A["पहले से जमा audio बढ़ाएँ"] --> B["Refill delay absorb करना आसान"]
    B -->|"बदले में"| C["नया audio पीछे wait करता है"]
    C --> D["Action से sound तक देरी"]

चित्र 7: Buffer बढ़ाना response speed की कीमत पर headroom बनाने वाला adjustment है।

न “जितना छोटा उतनी बेहतर performance” सही है, न “जितना बड़ा उतना सही”। ज़रूरी response speed बनाए रखते हुए इतना headroom रखें कि audio न कटे।

Buffer बढ़ाने वाला adjustment temporary supply delay के लिए headroom बनाता है। अगर average supply ही consumption के बराबर नहीं चल पा रही, तो limited buffer बढ़ाने से बस data खत्म होने तक का समय बढ़ता है, और device disconnect की समस्या भी हल नहीं होती। यह इस बात की recommendation भी नहीं है कि exclusive mode इस्तेमाल करने से सब ठीक हो जाएगा। Exclusive-Mode Streams

48kHz पर 480 frames का audio

PCM frame एक ही समय-बिंदु पर play होने वाले सभी channels के samples को मिलाकर बनी unit है। Stereo होने का मतलब यह नहीं कि time निकालने के लिए frame count को दोगुना किया जाए। Frames से दर्शाए गए audio की length “frame count ÷ sample rate” से निकलती है; 48kHz पर 480 frames हों तो 480 ÷ 48000 सेकंड, यानी 10 ms। 48kHz रखते हुए frame count बढ़ाएँ, तो जमा किए जा सकने वाले audio का time भी बढ़ जाता है। Rendering a Stream

यह time key दबाने से आवाज़ सुनाई देने तक की total latency से अलग है, क्योंकि उसमें ऐप, driver, device, और दूसरे buffers व processing का समय भी जुड़ता है। DAW की setting values भी unit और किस buffer की बात हो रही है, यह देखकर ही पढ़ें। Low Latency Audio

flowchart TB
    accTitle: Frame count से निकाला time और total latency
    accDescr: 480 frames को 48000 से भाग देकर मिला 10 ms buffer का दर्शाया time है; इसमें ऐप, driver, device वगैरह की processing जुड़कर key से sound तक की total latency बनती है।
    A["480 ÷ 48000"] --> B["Buffer के 10 ms"]
    B -->|"दूसरी processing भी जुड़ती है"| C["Key से sound तक total latency"]

चित्र 8: Frame count से निकाला time total latency का सिर्फ़ एक हिस्सा है।

Reproduce conditions compare करें

पहले वह combination narrow down करें जिसमें problem reproduce होती है, और ज़रूरत हो तभी detailed recording पर जाएँ। नीचे दिए steps cause की जाँच के लिए हैं; यह सारे setting changes एक साथ कर देने वाली fixes की list नहीं है।

अपना काम save करें, live meeting या recording खत्म करें, और फिर ऐसे volume पर test करें जो कानों पर ज़ोर न डाले। Original output destination, audio enhancements, buffer value वगैरह note कर लें, ताकि वापस पहले जैसा किया जा सके। जो setting उपलब्ध नहीं है उसे skip करें; setting दिखाने के लिए Registry वगैरह में बदलाव न करें।

1. एक ही छोटा audio source और observation time तय करें, और original conditions में problem reproduce होती है या नहीं, check करें।

   Windows version, ऐप का नाम और version, output device, connection type और driver version record करें। Dropout का समय, उस वक्त किया गया operation और वह कितनी बार हुआ, यह भी note करें। अगर original conditions में reproduce न हो, तो इसे improvement न मानें और reproduce करने वाली conditions ढूँढने पर लौटें।

2. नीचे की table से एक comparison चुनें और सिर्फ़ वही condition बदलकर play करें।

   Compare की जाने वाली condition	क्या देखना है
   Locally saved audio source बनाम network से playback	क्या यह सिर्फ़ network से play करने पर होता है? Content वही हो पर format या processing path अलग हो, तो वह भी record करें।
   वही audio source किसी दूसरे ऐप में play करें	क्या यह किसी खास ऐप में ज़्यादा होता है?
   Bluetooth जैसा output बनाम built-in या wired output	क्या यह किसी खास output path में ज़्यादा होता है?
   Audio enhancements on बनाम off	क्या effect processing के साथ combination से फ़र्क पड़ता है?
   DAW वगैरह में current buffer बनाम एक step बड़ी value	क्या पहले से जमा करने का headroom बढ़ाने पर फ़र्क पड़ता है? Action से sound तक की देरी भी acceptable है या नहीं?

3. Audio enhancements compare करने हों, तो जिस output की जाँच हो रही है उस पर setting कुछ समय के लिए off करें।

   Windows में “Settings” → “System” → “Sound” पर जाकर target output चुनें, और जहाँ उपलब्ध हो वहाँ “Audio enhancements” off करें। अगर display अलग हो या यह option न हो, तो उस version या device की guidance देखें। Fix distorted or crackling audio in Windows

4. बदली गई setting को वापस पहले जैसा करें और उसी audio source और observation time के साथ फिर से test करें।

   “Original condition”, “एक बदलाव वाली condition” और “वापस पहले जैसी की गई condition” के results साथ-साथ रखें। जिस बदलाव से कोई असर न हो उसे पहले जैसा करके ही अगले comparison पर जाएँ। Settings के combinations बदलते रहने से पता नहीं चलता कि असल में किस चीज़ से फ़र्क पड़ा।

5. Driver बदलकर देखना हो, तो पहले official distribution और recovery का तरीका confirm करें, फिर बदलें।

   Windows Update या device manufacturer का official distribution इस्तेमाल करें, और बदलाव से पहले और बाद का version व settings record करें। पहले से check कर लें कि वापस पुराने पर जा सकते हैं या नहीं, और managed PC हो तो admin से बात करें। Update के तुरंत बाद एक बार ठीक play हो जाने को solution न मानें; उन्हीं reproduce conditions में confirm करें। Fix distorted or crackling audio in Windows

जो result चाहिए वह ऐसा record है जो symptom को condition से जोड़े, जैसे “इस ऐप में, इस output के साथ reproduce होता है”। अगर कोई setting मिल जाए जिससे सुधार हो, तब भी उसे cause की पुष्टि से अलग रखें।

flowchart TB
    accTitle: एक condition बदलकर फिर पहले जैसा करने वाला comparison
    accDescr: उसी audio source से reproduce check करें, ऐप या output जैसी एक condition बदलें, और पहले जैसा करने पर आया result भी record करें।
    A["Original combination में play"] --> B["एक condition बदलकर play"]
    B --> C["पहले जैसा करके play"]
    C --> D["Dropout की condition और समय note"]

चित्र 9: एक बार ठीक हो जाने से ज़्यादा ज़रूरी यह confirm करना है कि condition और symptom बार-बार साथ दिखते हैं।

Condition बदलने से पहले और बाद reproducibility

“Symptom दब गया”, “condition narrow down हो गई” और “root cause पहचान लिया” अलग-अलग stages हैं। जितना observe हो पाया, conclusion उसी हिसाब से record करें।

flowchart TB
    accTitle: Condition से संबंध दिखाने वाले तीन results
    accDescr: Original condition में reproduce हो, एक condition बदलने पर सुधार हो और वापस करने पर फिर reproduce हो, तो यह उस condition से संबंध का संकेत है, पर इसे cause की पुष्टि से अलग रखा जाता है।
    A["Original condition में reproduce"] --> B["एक बदलाव से सुधार"]
    B --> C["वापस करने पर reproduce"]
    C --> D["उस condition से संबंध का संकेत"]

चित्र 10: तीनों बातें मिल जाएँ, तब भी पता सिर्फ़ संबंध के संकेत तक ही चलता है।

कम CPU usage इस बात का सबूत नहीं कि audio की deadline पूरी हुई। साथ ही, सिर्फ़ dropout हुआ इसलिए यह भी नहीं कहा जा सकता कि refill delay ही root cause था। Audio source, ऐप की processing, effects, output path वगैरह compare करें, और जितना observe हुआ उसी के आधार पर निर्णय लें। Fix distorted or crackling audio in Windows

कोई temporary workaround अपनाएँ, तो original setting, क्या बदला, observation time, problem दोबारा हुई या नहीं, और कितनी latency acceptable है, यह सब note करें। Root cause अभी तय न हुआ हो, तो यह बात भी record करें।

WPR से audio dropout record करें

यह तब करें जब सिर्फ़ conditions compare करके narrow down न हो, या driver side की processing की जाँच करनी हो। WPR recording के लिए और WPA save की गई timeline के analysis के लिए इस्तेमाल होने वाले tools हैं। Windows Performance Toolkit, recording के लिए ज़रूरी permissions और ETL save करने की जगह तैयार रखें। Managed PC पर tool install करके record करना हो, तो admin से request करें। Display names और उपलब्ध profiles install किए गए version में ही check करें। Windows Performance Recorder

ETL में process names, file paths वगैरह हो सकते हैं। Record करने से पहले company के rules और किसके साथ share करना है, यह confirm करें, और file को किसी public जगह पर वैसे ही attach न करें। अगर कोई दूसरा recording session चल रहा हो, तो उसे अपनी मर्ज़ी से बंद न करें; ज़िम्मेदार व्यक्ति से पूछें। WPR How-to Topics

1. WPR में “More Options” खोलें और अपने मकसद के हिसाब से recording profile चुनें।

   Built-in profiles में “Audio glitches” और “CPU usage” शामिल हैं। ऐसी setting चुनें जिससे audio की discontinuity और CPU activity दोनों देखी जा सकें। उपलब्ध profiles, display names और क्या collect होता है, यह install किए गए version में check करें, और सभी types को लंबे समय तक record करने वाली setting न रखें। Built-in Recording Profiles

2. Dropout reproduce करने से पहले recording शुरू करें।

   अगर existing recording रोकने का confirmation आए, तो आगे न बढ़ें; start cancel करें और ज़िम्मेदार व्यक्ति से पूछें। Conditions को बिना recording वाली स्थिति जैसा ही रखें, और इस संभावना को भी खुला रखें कि recording के load से ही symptom बदल जाए। WPR How-to Topics

3. Comparison में मिली condition में play करें, और dropout का समय और उस वक्त का operation note करें।

   Symptom से पहले और बाद का थोड़ा सा problem-free हिस्सा भी शामिल करें। जिस recording में reproduce नहीं हुआ, उसमें यह बात साफ़ लिखें और उसे cause capture करने वाली recording न मानें।

4. Reproduce होने के बाद “Save” से recording खत्म करें और ETL file save करें।

   “Cancel” करने पर file save नहीं होती। Save location, reproduce conditions, recording हुई या नहीं, और event loss की warning आई या नहीं, यह note करें। जिस recording में events lost हों, उसमें न दिखने वाले हिस्से को normal न मानें। WPR How-to Topics

ETL file और dropout के समय, operation और conditions के notes हों, तो WPA में match करने की तैयारी पूरी है। सिर्फ़ recording save हो जाने से यह ज़रूरी नहीं कि ज़रूरी events capture हुए हों। Content अगले section “Dropout से पहले-बाद execution और wait” में check करें।

flowchart TB
    accTitle: Dropout वाली छोटी recording लें
    accDescr: WPR में recording शुरू करें, symptom reproduce करके समय note करें, फिर रोककर save की गई recording को WPA में देखें।
    A["WPR में recording शुरू"] --> B["उसी condition में dropout reproduce"]
    B --> C["समय और operation note करके save"]
    C --> D["WPA में पहले-बाद का हिस्सा zoom"]

चित्र 11: Symptom खत्म होने के बाद CPU usage देखना काफ़ी नहीं; जिस हिस्से में symptom आया उसकी recording चाहिए।

Dropout से पहले-बाद execution और wait

Save की गई ETL और reproduce के समय के notes तैयार रखें। नीचे के steps WPA में जाँच का starting point हैं। Stack और symbols सहित detailed analysis की ज़रूरत पड़े, तो recording को सावधानी से handle करते हुए admin या developer से request करें।

1. ETL को WPA में खोलें, और capture हुए audio events और reproduce के समय के आधार पर dropout से पहले और बाद के हिस्से को zoom करें।

   Comparison के लिए वह हिस्सा भी रखें जहाँ symptom नहीं है। सिर्फ़ maximum values की ranking न देखें; एक ही time range पर align करके compare करें।

2. उसी range में “DPC/ISR” और “CPU Usage (Precise)” देखें।

   ज़रूरी data न हो, तो check करें कि profile उसे capture कर सकता है या नहीं, और WPR recording पर लौटें। Recording न होना और problem न होना अलग बातें हैं। CPU Analysis, Built-in Recording Profiles

3. पहचानें कि audio से जुड़ा thread run होने के लिए ready होकर अपनी बारी की wait कर रहा था, या data जैसी किसी चीज़ की wait कर रहा था।

   पहली स्थिति में, match करें कि संबंधित logical CPU पर DPC/ISR जैसी कोई चीज़ लंबे समय तक तो नहीं चल रही थी। दूसरी स्थिति में, capture हुए events या stacks से पता करें कि wait किसने खत्म की। Running thread भी interrupt से रुक सकता है, इसलिए सिर्फ़ Ready time तक सीमित न रहें; DPC/ISR के intervals भी overlay करें। CPU Analysis

4. Dropout के साथ time का मेल, संबंधित CPU और conditions बदलने के results एक साथ record करें।

   लंबे DPC/ISR का सिर्फ़ module name देखकर किसी खास device या driver को cause तय न करें। हो सकता है आप किसी दूसरे समय की बड़ी value देख रहे हों, या ऐसा common हिस्सा जिससे कई devices गुज़रते हैं।

flowchart TB
    accTitle: Dropout वाले हिस्से में wait का प्रकार जाँचें
    accDescr: Dropout से पहले-बाद के हिस्से को zoom करके audio thread की state देखें। Ready होकर बारी की wait हो तो उसी CPU के DPC या ISR से match करें, और data जैसी wait हो तो wait खत्म करने वाली processing का पता करें।
    A["Dropout के आसपास zoom"] --> B{"Thread की state"}
    B -->|"बारी की wait"| C["DPC/ISR"]
    B -->|"Data की wait"| D["Wait खत्म करने वाली processing"]

चित्र 12: सिर्फ़ maximum values न उठाएँ; उन्हें उस हिस्से के साथ मिलाकर पढ़ें जहाँ audio processing की ज़रूरत थी।

Cause पहचान में न आए, तो investigation को “अभी तय नहीं” के रूप में आगे hand over करें। साथ में दें: OS, ऐप, device और driver के versions, reproduce steps, बदलाव से पहले और बाद के results, घटना का समय, collection profile, और event loss की warning थी या नहीं। ETL को company rules के अनुसार सिर्फ़ उसी के साथ share करें जो investigation कर रहा है।

Audio ऐप में read-ahead

अगर आप ख़ुद audio ऐप बना रहे हैं, तो design ऐसा रखें कि अगला buffer भरने वाली processing हर बार deadline के अंदर पूरी हो। WASAPI में एक तरीका है जिसमें buffer process करने का सही समय event के ज़रिए मिलता है। Exclusive-Mode Streams

MMCSS time constraints वाली multimedia processing के threads को CPU resources allocate करने वाला mechanism है। इसमें disk से data पहले से तैयार करने या lock wait हटाने जैसी कोई feature नहीं है। MMCSS से allocation इस्तेमाल करें, तब भी data तैयार करने और wait घटाने का design अलग से चाहिए। Multimedia Class Scheduler Service

flowchart TB
    accTitle: MMCSS का दायरा
    accDescr: MMCSS time constraint वाली processing के threads को CPU resources देता है, लेकिन data तैयार करना और lock wait घटाना अलग design से होता है।
    M["MMCSS: CPU resources allocate"] -.->|"अलग से चाहिए"| D["Data तैयारी और wait में कमी"]

चित्र 13: CPU resources allocate करना और data को समय पर तैयार रखने वाला design, दो अलग काम हैं।

Design का principle है: file या network से पढ़ने वाली processing को audio देने वाली processing से अलग रखें। जिस तैयारी में कितना समय लगेगा यह predict करना मुश्किल हो, उसे पहले ही कर लें, और data के handoff के लिए पहले से allocate किया गया buffer इस्तेमाल करें। Audio side को ऐसा बनाएँ कि उसे UI के जवाब, लंबे lock या synchronous log writing की wait न करनी पड़े।

flowchart TB
    accTitle: Unpredictable समय वाली तैयारी को audio supply से अलग रखें
    accDescr: यह design reading जैसे काम पहले से करता है और तैयार data buffer के ज़रिए audio processing को देता है, ताकि deadline से ठीक पहले लंबी wait कम हो।
    A["Read-ahead में data तैयार"] --> B["पहले से allocated handoff area"]
    B --> C["Audio processing ज़रूरी हिस्सा देती है"]
    C --> D["Audio output तक supply"]

चित्र 14: समय लेने वाले काम को audio handoff से ठीक पहले वाले समय से हटा दें।

तैयारी वाला side लंबे समय तक रुक जाए, तो इस separation के बावजूद जमा data खत्म हो जाता है। सिर्फ़ average processing time ही नहीं, बल्कि वे मौके जब processing या wait लंबी हुई, और supply कितनी बार नहीं हो पाई, यह भी ऐसे तरीके से record करें जिससे audio processing में रुकावट न आए। असल में चुना गया buffer size और period API या driver से check करें; यह न मानें कि आपकी दी गई value ही वैसे की वैसे apply हो गई। Rendering a Stream, Low Latency Audio

Numerical examples और design examples दोनों समझाने के लिए हैं; ये किसी खास device के लिए recommended setting values नहीं हैं, और न ही इस बात की guarantee कि किसी भी environment में audio नहीं कटेगा।

Realtime priority का असर

User का पूरे player को “Realtime” priority पर बदलना हम हर स्थिति के लिए recommend नहीं करते। इससे दूसरी ज़रूरी processing में रुकावट आने का ख़तरा है, और normal thread priority बढ़ाने से DPC/ISR या data/lock की wait खत्म नहीं हो जाती। Development में MMCSS जैसे mechanisms और ऐसा design इस्तेमाल करें जो audio supply में लंबी wait न लाए। Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Realtime priority पर बदलने के बाद भी बची रहने वाली wait
    accDescr: Player को Realtime priority पर करने पर भी normal thread उसी CPU पर DPC या ISR से आगे नहीं निकल सकता, data या lock की wait भी बनी रहती है, और दूसरी ज़रूरी processing में रुकावट का ख़तरा भी है।
    A["Player को Realtime priority पर"] --> B["DPC/ISR से आगे नहीं"]
    B --> C["Data/lock की wait बनी रहती है"]
    C --> D["दूसरी processing रुकने का ख़तरा"]

चित्र 15: Priority बढ़ाने पर भी audio refill को late करने वाली wait बनी रहती है।

संबंधित लेख

• Windows की “Processor scheduling” और background services setting
• Windows में disk 100% की वजह सुरक्षित तरीके से पता करें
• Network तेज़ है, फिर भी RDP slow क्यों?

संदर्भ

• Microsoft Learn, Rendering a Stream। Playback buffer में supply, बचा हुआ data, असली buffer size, और PCM frame की definition।
• Microsoft Learn, Exclusive-Mode Streams। Buffer supply का timing और audio glitches, latency के साथ balance, और event-driven supply। यह संदर्भ exclusive mode को हर स्थिति के लिए recommend करने के लिए नहीं दिया गया है।
• Microsoft Learn, Low Latency Audio। Windows का audio path, buffer, device और effects processing का latency से संबंध, और low latency के tradeoffs।
• Microsoft Learn, CPU Analysis। Logical CPU, thread की Ready/Waiting state, DPC/ISR और thread execution का संबंध, और WPA में CPU analysis।
• Microsoft Learn, Introduction to DPCs। Interrupt handling को छोटा रखकर बाकी काम DPC को सौंपने का mechanism।
• Microsoft Learn, Results for the Streaming Media Performance Assessment। लंबे और बार-बार आने वाले DPC/ISR, data supply की कमी और audio glitches। हम assessment की warning values को सभी devices के लिए safety threshold के रूप में generalize नहीं करते।
• Microsoft Support, Fix distorted or crackling audio in Windows। Audio enhancements, format, driver वगैरह की जाँच।
• Microsoft Learn, Windows Performance Recorder। ETW recording और WPA से analysis, और Windows Performance Toolkit का इस्तेमाल।
• Microsoft Learn, Built-in Recording Profiles। WPR का More Options, और Audio glitches व CPU usage जैसे built-in profiles।
• Microsoft Learn, WPR How-to Topics। Recording शुरू करना और Save से save करना, existing session से conflict, और personal information व event loss से जुड़ी सावधानियाँ।
• Microsoft Learn, Multimedia Class Scheduler Service। Time constraints वाली multimedia processing को CPU resources का allocation।
• Microsoft Learn, Scheduling Priorities। Process और thread priority, और Realtime priority से जुड़ी सावधानी।

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये इस विषय से जुड़े topic पृष्ठ हैं। लेख से शुरू करके आप संबंधित सेवाओं और दूसरे लेखों तक जा सकते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख नीचे दिए गए सेवा पृष्ठों से जुड़ता है। जो प्रवेश-बिंदु आपके सबसे क़रीब हो, वहाँ से देखिए।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

CPU usage सिर्फ़ 10% के आसपास है, फिर भी audio क्यों कटता है?

Audio की एक deadline होती है: play हो रहा data खत्म होने से पहले अगला data refill करना पड़ता है। पूरे CPU का usage कम होने पर भी, अगर उस क्षण audio processing run न हो पाए या ज़रूरी data की wait कर रही हो, तो refill समय पर न पहुँचे, ऐसा हो सकता है। हर audio dropout की यही वजह हो, यह ज़रूरी नहीं; output device या ऐप बदलकर compare करना भी ज़रूरी है।

क्या audio buffer बड़ा करने से dropout ठीक हो जाता है?

अगर refill कुछ समय के लिए late हो रहा हो, तो बड़ा buffer उसे absorb कर सकता है। लेकिन जमा किए गए audio के play होने तक की wait भी बढ़ जाती है। यह setting processing capacity की लगातार कमी या device disconnect को हल नहीं करती। जिन ऐप्स या drivers में यह बदला जा सकता है, उनमें original value note करें और एक-एक step करके compare करें।

48kHz पर 480 frames कितने milliseconds का audio है?

480 ÷ 48000 सेकंड, यानी 10 ms। PCM का एक frame एक ही समय-बिंदु के सभी channels के samples को मिलाकर बनी unit है। यह value उतने frames से दर्शाए गए audio की length है, device और ऐप सहित total latency नहीं।

क्या लंबे DPC या ISR execution time वाला driver ही audio dropout का culprit है?

वह एक candidate हो सकता है, लेकिन सिर्फ़ execution time की ranking से इसे confirm नहीं किया जा सकता। जिस हिस्से में dropout हुआ, उसे audio thread की wait और उसी CPU पर DPC/ISR execution से match करें। सिर्फ़ module name देखकर किसी खास device या driver में bug है, ऐसा तय न करें; reproduce conditions बदलकर मिले results भी check करें।

क्या player को Realtime priority पर करने से सुधार होता है?

हम इसे हर स्थिति के लिए recommend नहीं करते। Normal thread की priority बढ़ाने पर भी वह उसी CPU पर normal DPC या ISR से आगे नहीं निकल पाता, और data या lock की wait भी खत्म नहीं होती। Developer MMCSS जैसे mechanism और wait न लाने वाला design इस्तेमाल करें; user पहले reproduce conditions और output path compare करें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच पर केंद्रित; जिन परियोजनाओं में मौजूदा assets बचे हैं, उनमें और जिन खराबियों का कारण आसानी से नहीं दिखता, उनकी जाँच में हमारी विशेष ताकत है।