Windows Audio format: sample rate, bit depth and load
On this page
Short answer: on the tested Realtek USB Audio endpoint, the 48 kHz / 24-bit format remained the practical choice. Switching to 96 or 192 kHz did not reduce the available audio engine period or the XAudio2 queue estimate. The 16-bit advantage in CPU and the benefit of disabling system effects were not confirmed.
Status: measured on one system, not reproduced on another device. The result cannot be automatically transferred to another audio driver, DAC or Windows build. The meaning of the statuses is described in the research methodology.
What was tested
Section titled “ What was tested”The study answered four questions:
- Does the shared-mode audio engine period decrease when the rate is increased?
- Does 16-bit reduce load relative to 24-bit and 32-bit at 48 kHz?
- Does disabling system sound effects give a reproducible reduction in load?
- How is a change in endpoint rate related to the internal operation of XAudio2 for a 48 kHz source?
The measurement did not test sound quality, FPS, game latency or the physical latency between the digital signal and the speaker.
Scope of the study
Section titled “ Scope of the study”| Parameter | Value |
|---|---|
| Measurement date | 2026-08-20 |
| Windows | Windows 11 Pro 25H2, x64 |
| OS build | 26200.8655 |
| Processor | AMD Ryzen 7 7800X3D, 8 cores / 16 threads |
| RAM | 32 GB |
| Device | Speakers, Realtek USB Audio |
| Driver | Realtek USB Audio 6.4.0.2422 dated 2025-08-07 |
| Source device format | 48 kHz, 24-bit PCM, stereo |
| Shared mix format | 48 kHz, 32-bit float, stereo |
| Source effects | Enabled |
| Test cases | 17 traces, one trace per case |
| Trace analysis | Five consecutive 10-second windows |
The source trace recorded the Windows build 26200 branch and the audio device data. The full revision, Windows edition, processor model and memory size were additionally read from the same computer on 2026-08-24. Four days passed between the measurement and the repeated recording of the configuration.
The unique endpoint identifier and the raw system traces are not published.
Methodology
Section titled “ Methodology”The cases were run in random order. For each one, 3 seconds of warm-up were used, followed by 52 seconds of system tracing and five 10-second analysis windows.
Two types of load were tested:
- a steady shared-mode WASAPI stream for comparing rate, bit depth and effects;
- a synthetic XAudio2 load with 8, 32 or 64 active voices and 44.1 or 48 kHz sources.
The main Windows Audio metric is the scheduler running time of the audiodg.exe process, expressed in milliseconds of work per second. XAudio2 performance data, the number of glitches and trace loss statistics were read separately.
The five windows of one trace are correlated and are used only as a descriptive spread. They are not five independent runs. The overall background system load varied, so whole-machine CPU, absolute DPC and ISR were not used for the final conclusion.
Audio engine period
Section titled “ Audio engine period”| Endpoint rate | Frames | Period |
|---|---|---|
| 44.1 kHz | 441 | 10.0 ms |
| 48 kHz | 480 | 10.0 ms |
| 96 kHz | 960 | 10.0 ms |
| 192 kHz | 1920 | 10.0 ms |
The endpoint returned only a 10 ms period. Periods of 5 ms and 2.5 ms were not supported by its driver. Increasing the rate increased the number of frames per period, but did not reduce the duration of the period.
This is a property of the specific combination of device and driver. Microsoft states that the available buffer sizes are determined by the audio driver, and an application can request the supported options via IAudioClient3. More details: Low Latency Audio.
Rate and audiodg
Section titled “ Rate and audiodg”The table shows the median and range of five windows within a single trace. The unit мс/с shows how many milliseconds the audiodg.exe process executed per second of observation.
| Endpoint rate | audiodg, median | Window range |
|---|---|---|
| 44.1 kHz | 4.34 ms/s | 4.24–4.86 ms/s |
| 48 kHz | 4.23 ms/s | 4.20–5.63 ms/s |
| 96 kHz | 4.77 ms/s | 4.72–5.70 ms/s |
| 192 kHz | 5.19 ms/s | 5.07–5.94 ms/s |
In this series, 96 and 192 kHz did not show a reduction in audiodg.exe time. But there was one trace per rate, and the background load varied. The table does not prove a universal size of the CPU difference between rates.
Bit depth at 48 kHz
Section titled “ Bit depth at 48 kHz”| Device format | audiodg, median | Window range |
|---|---|---|
| 16-bit | 4.07 ms/s | 4.03–4.35 ms/s |
| 24-bit | 4.23 ms/s | 4.20–5.63 ms/s |
| 32-bit | 4.20 ms/s | 4.16–4.64 ms/s |
The ranges overlap, and there are not enough independent repeats. Based on this series, it cannot be stated that switching to 16-bit gives a reproducible reduction in load.
System effects
Section titled “ System effects”At 48 kHz / 24-bit, the median audiodg.exe was 4.23 ms/s with effects enabled and 4.39 ms/s with them disabled. The mean value moved in the other direction because of one higher window in the source trace.
No reliable benefit from disabling effects was established. The result is not a reason to disable them without a specific problem with an Audio Processing Object or driver.
XAudio2 and rate mismatch
Section titled “ XAudio2 and rate mismatch”For a fixed 48 kHz source and 32 voices, the following XAudio2 performance data were obtained:
| Endpoint rate | Audio cycles/s | Relative to 48 kHz | Queue estimate |
|---|---|---|---|
| 44.1 kHz | 25 116 | 2.31× | 37.28 ms |
| 48 kHz | 10 870 | 1.00× | 37.27 ms |
| 96 kHz | 55 574 | 5.11× | 37.18 ms |
| 192 kHz | 87 016 | 8.00× | 37.18 ms |
Microsoft defines AudioCyclesSinceLastQuery as the CPU cycles spent by XAudio2 processing audio since the previous request. CurrentLatencyInSamples is the approximate distance between the last data submitted to the driver and the data being played. See XAUDIO2_PERFORMANCE_DATA and IXAudio2::GetPerformanceData.
Increasing the endpoint rate in this synthetic case increased the internal work of XAudio2, but barely changed its queue estimate. One performance summary was obtained per variant, so the coefficients describe this run rather than being a universal prediction for games.
Measurement stability
Section titled “Measurement stability”Across all 17 traces, the following were recorded:
- 0 audio glitches;
- 0 lost ETW events;
- 0 lost ETW buffers.
What was confirmed
Section titled “ What was confirmed”- On the tested endpoint, the available shared-mode period remained 10 ms at 44.1, 48, 96 and 192 kHz.
- Increasing the rate did not reduce the measured XAudio2 queue in the synthetic case.
- The 16-bit advantage in
audiodg.exetime was not confirmed. - The benefit of disabling system effects was not confirmed.
- 48 kHz / 24-bit matches the source device format and showed no practical disadvantage compared with the neighbouring variants.
What was not confirmed
Section titled “ What was not confirmed”- The result was not reproduced on another audio device or Windows build.
- The full Windows revision and the overall computer configuration were recorded four days after the measurement, not within the source trace.
- Physical DAC, ADC, acoustic or input-to-sound latency was not measured.
- Sound quality and the audibility of differences were not assessed.
- The effect on specific games, FPS and frametime was not tested.
- The contribution of an individual vendor APO was not isolated.
- The exact overall CPU effect cannot be transferred to processors of different performance.
Limitations
Section titled “Limitations”The raw ETL files are not published: they contain unrelated information about process and system state. The tables above were manually selected and do not contain the unique endpoint ID, usernames, local paths or command lines.
The study and the tools used belong to the BoosterX developer, so the developer has a direct interest in the results. The methodology and the limits of applicability are described above, and the conclusions can be verified against the open data and the public sources listed.
Practical conclusion
Section titled “ Practical conclusion”For the tested device, it is reasonable to keep 48 kHz / 24-bit and not disable system effects without a specific diagnosed problem. Choosing 96 or 192 kHz for lower latency is not supported by this study.
This is not a universal setting for all DACs and drivers. A device that reports a shorter shared-mode period or uses a different audio path requires a separate measurement.
State restoration
Section titled “State restoration”After completion, 48 kHz / 24-bit PCM and the original state of the system effects were restored. No active tracing sessions remained.
Sources
Section titled “Sources”- Windows Performance Recorder — system event recording based on ETW.
- Windows 11 release information — correspondence of version 25H2 to the OS build 26200 branch.
- Low Latency Audio — audio engine period, the role of the driver and the capabilities of
IAudioClient3. - XAUDIO2_PERFORMANCE_DATA — cycles, queue latency and glitches values.
- IXAudio2::GetPerformanceData — obtaining XAudio2 performance data.
Study performed: 2026-08-20. Public sources and wording verified: 2026-08-24.
Change history
Section titled “Change history”- 2026-09-20: the structure was brought to the required one — “Limitations” and “State restoration” were separated into their own sections; decimal separators and time units were brought to the style of the series (comma, “ms”); a conflict-of-interest disclaimer was added.
- 2026-08-24: first publication; measurements on one system, the limits of transferring the result and state restoration were published.