इसे छोड़कर कंटेंट पर जाएं

Windows Audio प्रारूप: नमूना दर, बिट गहराई और लोड

इस पृष्ठ पर

संक्षिप्त उत्तर: जाँचे गए Realtek USB Audio endpoint पर प्रारूप 48 kHz / 24-bit व्यावहारिक विकल्प बना रहा। 96 या 192 kHz पर स्विच करने से उपलब्ध ऑडियो इंजन अवधि या XAudio2 कतार अनुमान कम नहीं हुआ। CPU पर 16-bit का लाभ और सिस्टम प्रभाव बंद करने का फ़ायदा पुष्ट नहीं हुआ।

स्थिति: एक सिस्टम पर मापा गया, किसी अन्य डिवाइस पर पुनरुत्पादित नहीं। परिणाम को स्वतः किसी अन्य ऑडियो ड्राइवर, DAC या Windows build पर लागू नहीं किया जा सकता। स्थितियों का अर्थ शोध पद्धति में वर्णित है।

शोध ने चार प्रश्नों का उत्तर दिया:

  1. क्या आवृत्ति बढ़ाने पर shared-mode ऑडियो इंजन की अवधि घटती है?
  2. क्या 48 kHz पर 16-bit, 24-bit और 32-bit की तुलना में लोड कम करता है?
  3. क्या सिस्टम ध्वनि प्रभाव बंद करने से लोड में पुनरुत्पाद्य कमी आती है?
  4. 48 kHz स्रोत के लिए XAudio2 के आंतरिक कार्य से endpoint rate का परिवर्तन कैसे संबंधित है?

मापन ने ध्वनि गुणवत्ता, FPS, गेम विलंबता या डिजिटल सिग्नल और स्पीकर के बीच भौतिक विलंबता की जाँच नहीं की।

पैरामीटर मान
मापन की तिथि 2026-08-20
Windows Windows 11 Pro 25H2, x64
OS build 26200.8655
प्रोसेसर AMD Ryzen 7 7800X3D, 8 कोर / 16 थ्रेड
रैंडम एक्सेस मेमोरी 32 GB
डिवाइस स्पीकर, Realtek USB Audio
ड्राइवर Realtek USB Audio 6.4.0.2422, 2025-08-07 से
स्रोत device format 48 kHz, 24-bit PCM, stereo
Shared mix format 48 kHz, 32-bit float, stereo
स्रोत प्रभाव सक्षम
परीक्षण मामले 17 ट्रेस, प्रति मामला एक ट्रेस
ट्रेस विश्लेषण 10 सेकंड की पाँच क्रमिक विंडो

स्रोत ट्रेस ने Windows build 26200 की शाखा और ऑडियो डिवाइस डेटा रिकॉर्ड किया। पूर्ण revision, Windows edition, प्रोसेसर मॉडल और मेमोरी की मात्रा अतिरिक्त रूप से उसी कंप्यूटर से 2026-08-24 को पढ़ी गई। मापन और कॉन्फ़िगरेशन की पुनः रिकॉर्डिंग के बीच चार दिन बीते।

endpoint का अद्वितीय पहचानकर्ता और कच्चे सिस्टम ट्रेस प्रकाशित नहीं किए जाते।

मामले यादृच्छिक क्रम में निष्पादित किए गए। प्रत्येक के लिए 3 सेकंड का वार्म-अप, फिर 52 सेकंड की सिस्टम ट्रेसिंग और विश्लेषण की पाँच 10-सेकंड विंडो का उपयोग किया गया।

दो प्रकार के लोड की जाँच की गई:

  • आवृत्ति, बिट गहराई और प्रभावों की तुलना के लिए स्थिर shared-mode WASAPI स्ट्रीम;
  • 8, 32 या 64 सक्रिय voices और 44,1 या 48 kHz स्रोतों के साथ सिंथेटिक XAudio2 लोड।

Windows Audio का मुख्य संकेतक audiodg.exe प्रक्रिया का scheduler running time है, जिसे प्रति सेकंड कार्य के मिलीसेकंड में व्यक्त किया जाता है। अलग से XAudio2 performance data, glitches की संख्या और ट्रेस हानि के आँकड़े पढ़े गए।

एक ही ट्रेस की पाँच विंडो सहसंबद्ध हैं और केवल वर्णनात्मक प्रसार के रूप में उपयोग की गई हैं। वे पाँच स्वतंत्र रन नहीं हैं। सिस्टम का समग्र पृष्ठभूमि लोड बदलता रहा, इसलिए whole-machine CPU, निरपेक्ष DPC और ISR का उपयोग अंतिम निष्कर्ष के लिए नहीं किया गया।

ऑडियो इंजन की अवधि

Section titled “ ऑडियो इंजन की अवधि”
Endpoint rate Frames अवधि
44,1 kHz 441 10,0 मि.से.
48 kHz 480 10,0 मि.से.
96 kHz 960 10,0 मि.से.
192 kHz 1920 10,0 मि.से.

Endpoint ने केवल 10 मि.से. की अवधि लौटाई। 5 मि.से. और 2,5 मि.से. की अवधियाँ उसके ड्राइवर द्वारा समर्थित नहीं थीं। आवृत्ति बढ़ाने से प्रति अवधि frames की संख्या बढ़ी, लेकिन अवधि की लंबाई कम नहीं हुई।

यह डिवाइस और ड्राइवर के विशिष्ट संयोजन का गुण है। Microsoft बताता है कि उपलब्ध buffer आकार ऑडियो ड्राइवर निर्धारित करता है, और एप्लिकेशन IAudioClient3 के माध्यम से समर्थित विकल्पों का अनुरोध कर सकता है। अधिक जानकारी: Low Latency Audio।

तालिका में एक ही ट्रेस की पाँच विंडो की माध्यिका और सीमा दी गई है। इकाई мс/с दर्शाती है कि audiodg.exe प्रक्रिया एक सेकंड के अवलोकन में कितने मिलीसेकंड निष्पादित हुई।

Endpoint rate audiodg, median विंडो सीमा
44,1 kHz 4,34 मि.से./से. 4,24–4,86 मि.से./से.
48 kHz 4,23 मि.से./से. 4,20–5,63 मि.से./से.
96 kHz 4,77 मि.से./से. 4,72–5,70 मि.से./से.
192 kHz 5,19 मि.से./से. 5,07–5,94 मि.से./से.

इस श्रृंखला में 96 और 192 kHz ने audiodg.exe समय में कमी नहीं दिखाई। लेकिन प्रत्येक आवृत्ति के लिए एक ही ट्रेस था, और पृष्ठभूमि लोड बदलता रहा। तालिका आवृत्तियों के बीच सार्वभौमिक CPU अंतर सिद्ध नहीं करती।

Device format audiodg, median विंडो सीमा
16-bit 4,07 मि.से./से. 4,03–4,35 मि.से./से.
24-bit 4,23 मि.से./से. 4,20–5,63 मि.से./से.
32-bit 4,20 मि.से./से. 4,16–4,64 मि.से./से.

सीमाएँ एक-दूसरे को काटती हैं, और स्वतंत्र पुनरावृत्तियाँ अपर्याप्त हैं। इस श्रृंखला के आधार पर यह दावा नहीं किया जा सकता कि 16-bit पर स्विच करने से लोड में पुनरुत्पाद्य कमी आती है।

48 kHz / 24-bit पर audiodg.exe की माध्यिका सक्षम प्रभावों के साथ 4,23 मि.से./से. और अक्षम प्रभावों के साथ 4,39 मि.से./से. रही। स्रोत ट्रेस में एक अधिक ऊँची विंडो के कारण औसत मान दूसरी दिशा में बदला।

प्रभाव बंद करने का विश्वसनीय लाभ स्थापित नहीं हुआ। परिणाम Audio Processing Object या ड्राइवर की किसी विशिष्ट समस्या के बिना उन्हें बंद करने का आधार नहीं है।

XAudio2 और आवृत्ति का मेल न होना

Section titled “ XAudio2 और आवृत्ति का मेल न होना”

निश्चित 48 kHz स्रोत और 32 voices के लिए निम्नलिखित XAudio2 performance data प्राप्त हुए:

Endpoint rate Audio cycles/s 48 kHz के सापेक्ष कतार अनुमान
44,1 kHz 25 116 2,31× 37,28 मि.से.
48 kHz 10 870 1,00× 37,27 मि.से.
96 kHz 55 574 5,11× 37,18 मि.से.
192 kHz 87 016 8,00× 37,18 मि.से.

Microsoft AudioCyclesSinceLastQuery को पिछले अनुरोध के बाद XAudio2 द्वारा ऑडियो प्रसंस्करण पर खर्च किए गए CPU cycles के रूप में परिभाषित करता है। CurrentLatencyInSamples ड्राइवर को अंतिम बार भेजे गए और चलाए जा रहे डेटा के बीच अनुमानित दूरी है। देखें XAUDIO2_PERFORMANCE_DATA और IXAudio2::GetPerformanceData।

इस सिंथेटिक मामले में endpoint rate बढ़ाने से XAudio2 का आंतरिक कार्य बढ़ा, लेकिन उसका कतार अनुमान व्यावहारिक रूप से नहीं बदला। प्रत्येक विकल्प के लिए एक performance summary प्राप्त हुआ, इसलिए गुणांक इस रन का वर्णन हैं, न कि गेम के लिए सार्वभौमिक पूर्वानुमान।

सभी 17 ट्रेस में दर्ज हुआ:

  • 0 audio glitches;
  • 0 खोए ETW events;
  • 0 खोए ETW buffers.
  • जाँचे गए endpoint पर उपलब्ध shared-mode अवधि 44,1, 48, 96 और 192 kHz पर 10 मि.से. बनी रही।
  • आवृत्ति बढ़ाने से सिंथेटिक मामले में मापी गई XAudio2 कतार कम नहीं हुई।
  • audiodg.exe समय पर 16-bit का लाभ पुष्ट नहीं हुआ।
  • सिस्टम प्रभाव बंद करने का लाभ पुष्ट नहीं हुआ।
  • 48 kHz / 24-bit डिवाइस के स्रोत प्रारूप से मेल खाता है और इसने निकटवर्ती विकल्पों की तुलना में व्यावहारिक हानि नहीं दिखाई।

क्या पुष्ट नहीं हुआ

Section titled “ क्या पुष्ट नहीं हुआ”
  • परिणाम किसी अन्य ऑडियो डिवाइस या Windows build पर पुनरुत्पादित नहीं हुआ।
  • पूर्ण Windows revision और कंप्यूटर का समग्र कॉन्फ़िगरेशन मापन के चार दिन बाद रिकॉर्ड किया गया, न कि स्रोत ट्रेस के भीतर।
  • भौतिक DAC, ADC, acoustic या input-to-sound latency नहीं मापी गई।
  • ध्वनि गुणवत्ता और अंतरों की श्रवणता का मूल्यांकन नहीं किया गया।
  • विशिष्ट गेम, FPS और frametime पर प्रभाव की जाँच नहीं की गई।
  • किसी अलग vendor APO का योगदान पृथक नहीं किया गया।
  • सटीक समग्र CPU प्रभाव को अन्य क्षमता के प्रोसेसर पर लागू नहीं किया जा सकता।

कच्चे ETL प्रकाशित नहीं किए जाते: उनमें प्रक्रियाओं और सिस्टम की स्थिति से असंबंधित जानकारी होती है। ऊपर की तालिकाएँ मैन्युअल रूप से चुनी गई हैं और उनमें अद्वितीय endpoint ID, usernames, स्थानीय पथ या command lines नहीं हैं।

शोध और प्रयुक्त उपकरण BoosterX के डेवलपर के हैं, इसलिए डेवलपर का परिणामों में सीधा हित है। पद्धति और प्रयोज्यता की सीमाएँ ऊपर वर्णित हैं, और निष्कर्षों को खुले डेटा तथा सूचीबद्ध सार्वजनिक स्रोतों से सत्यापित किया जा सकता है।

व्यावहारिक निष्कर्ष

Section titled “ व्यावहारिक निष्कर्ष”

जाँचे गए डिवाइस के लिए 48 kHz / 24-bit बनाए रखना और किसी विशिष्ट निदानित समस्या के बिना सिस्टम प्रभाव बंद न करना उचित है। कम विलंबता के लिए 96 या 192 kHz का चुनाव इस शोध से समर्थित नहीं है।

यह सभी DAC और ड्राइवर के लिए सार्वभौमिक सेटिंग नहीं है। जो डिवाइस छोटी shared-mode अवधि बताता है या भिन्न ऑडियो पथ का उपयोग करता है, उसके लिए अलग मापन आवश्यक है।

समाप्ति के बाद 48 kHz / 24-bit PCM और सिस्टम प्रभावों की मूल स्थिति बहाल की गई। कोई सक्रिय ट्रेसिंग सत्र शेष नहीं रहा।

शोध पूर्ण: 2026-08-20। सार्वजनिक स्रोत और शब्दावली जाँचे गए: 2026-08-24।

परिवर्तन इतिहास

Section titled “परिवर्तन इतिहास”
  • 2026-09-20: संरचना को अनिवार्य रूप में लाया गया — «सीमाएँ» और «स्थिति की बहाली» को अलग अनुभागों में रखा गया; दशमलव विभाजक और समय इकाइयों को श्रृंखला की शैली (अल्पविराम, «मि.से.») में लाया गया; हितों के टकराव पर डिस्क्लेमर जोड़ा गया।
  • 2026-08-24: पहला प्रकाशन; एक सिस्टम पर मापन, परिणाम के स्थानांतरण की सीमाएँ और स्थिति की बहाली प्रकाशित।