Why Does Audio Drop Out Even Though CPU Usage Is Low? — Reasoning from Buffers and Deadlines

You are listening to music, and every so often the sound cuts out with a brief pop. Task Manager shows CPU usage hovering around 10%, yet the audio alone is unstable. In a case like this, why does the audio drop out even though the CPU has capacity to spare?

Even when CPU usage is low, audio can drop out if the refill of the next audio data misses its deadline. That is because the next data has to be handed over while the audio left in the buffer is still playing. The refill can be delayed by waits on data or locks, by DPCs/ISRs on the logical CPU it needs, and so on, without the CPU as a whole being used up. Exclusive-Mode Streams, CPU Analysis

That said, the pop you hear is not enough on its own to conclude that an underrun occurred. Similar symptoms can also come from the audio source, the app, audio effects, the output device, and so on. First compare using the same audio source, changing conditions one at a time and then changing each one back; if that still does not narrow it down, record the period before and after the dropout. Fix distorted or crackling audio in Windows

This article takes up that question and the ones that follow from it: “Should I just make the buffer bigger?” and “What should I compare, and what should I record, to narrow down the cause?” It does not establish the cause of any individual failure from CPU usage or the sound you hear alone.

The main focus is audio output on Windows 11. Built-in, wired, USB, Bluetooth and other outputs are the subjects of comparison, and for music production software (DAWs), the article also covers comparisons where the app or driver provides a buffer setting. It does not comprehensively cover the design of recording systems as a whole, or the diagnosis of wireless communication for each device.

The explanation uses shared mode as the basic example. The actual path, buffer size and processing period vary by app, API, driver and device, and there is no buffer settings screen common to every app. Low Latency Audio

The CPU usage, the 10 milliseconds remaining, the refill times and similar figures shown here are assumptions for the sake of explanation. They are not a report of reproduction or improvement measured on a particular PC. The operations in the second half are checking procedures for you to carry out in your own environment.

You can read about the mechanism in order, starting with the next section, “Audio Playback Buffer.” The operations for investigating dropouts are in “Comparing Reproduction Conditions” and “Recording Dropouts with WPR.”

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (5 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

Audio Playback Buffer

Simply having a music file saved does not make the speakers play. An app prepares the audio data and delivers it to the output device through Windows and the driver. The audio playback buffer is an area that temporarily holds the data to be played next. While the device plays the current data, the supplying side prepares the next data and refills the buffer. Rendering a Stream

flowchart TB
    accTitle: Holding audio a little ahead before playing it
    accDescr: The flow of refilling the buffer with prepared audio data and preparing the next data while playback on the device side continues.
    A["Prepare next audio"] --> B["Refill the buffer"]
    B --> C["Play buffered audio"]
    C -.->|"before it runs out"| A

Figure 1: For playback to continue, the refill has to keep up with the side that consumes the audio.

Figure 1 is a conceptual diagram that shows only the relationship between refilling and consumption. It does not treat the multiple buffers along the actual audio path as one physical area. Low Latency Audio

The buffer’s role is to absorb short timing gaps between the side that prepares the audio and the side that uses it, and so keep playback continuous. However, the buffer’s capacity and the amount of unplayed data currently in it are two different things. “It has a capacity of 10 milliseconds” does not mean that 10 milliseconds’ worth is always left. Rendering a Stream

In this article, the timing constraint of delivering the next data needed before the data being played is used up is called the refill deadline. Audio processing is work that requires “it was ready by the time it had to sound.” “It got computed in the end” is not enough. The state in which supply fails to keep up and the data to be played runs out is an underrun, and it leads to dropouts and clicks. Even if the data arrives late, a gap that has already been heard cannot be filled in afterward. Exclusive-Mode Streams

The Path of Audio Data

In ordinary shared mode, the Windows audio engine receives the data prepared by the playback app, mixes multiple sounds and applies effects, and then passes the result to the driver and the output device. The playback app is involved both in reading the audio source and in supplying the output, while the driver and the output device carry the data to the device side and play it. Low Latency Audio

flowchart TB
    accTitle: The path audio data takes in shared mode
    accDescr: The audio engine mixes the data prepared by the playback app and applies effects, passes it to the driver, and the output device plays it.
    A["Playback app: prepares data"] --> E["Audio engine: mixing, effects"]
    E --> D["Driver: carries to device"]
    D --> O["Output device: plays"]

Figure 2: An example in shared mode. The processing and buffers along the way vary by API and device.

The device side may also have its own processing and buffers, so the app-side buffer alone does not determine the overall latency. This explanation assumes the shared-mode path; it does not mean that every API goes through the same processing. Low Latency Audio

Refilling with 10 Milliseconds Left

Suppose the buffer currently has 10 milliseconds’ worth of unplayed data left. If the next refill comes 8 milliseconds later, playback carries on while some data remains; but if the refill cannot happen until 12 milliseconds later, then in this simplified example the data runs out at the 10-millisecond mark.

flowchart TB
    accTitle: The same 10 milliseconds left, a different outcome depending on refill time
    accDescr: As an assumption for explanation, with 10 milliseconds of playback data left, a refill after 8 milliseconds is in time, while one after 12 milliseconds comes after the data has been used up.
    A["10 ms left"] --> B{"Next refill"}
    B -->|"after 8 ms"| C["Carries on"]
    B -->|"after 12 ms"| D["Runs out at 10 ms"]

Figure 3: An example with simplified timing. What matters is not only whether the refill happened, but when.

CPU Usage and Late Refills

CPU usage shows how busy the CPU was over a period of time. That looks at something different from whether the audio processing could run at the moment it needed to. Even if the CPU has headroom for most of a second, if there is a single 12-millisecond span in which no refill can happen, that one delay can cause a dropout. Processing capacity left over afterward cannot win back a playback time that has already passed. CPU Analysis

flowchart TB
    accTitle: Average headroom and a single late refill
    accDescr: Even if the CPU has headroom for most of a second, a single 12-millisecond span with no refill can make the audio drop out from that one delay.
    A["Spare CPU most of the second"] --> B["One 12 ms span with no refill"]
    B --> C["Audio drops out that one time"]

Figure 4: Even with headroom on average, a playback time that has passed cannot be won back.

Computation time is not the only thing that eats into the deadline. The wait before processing starts and the wait until the needed data arrives count too. So the question for the investigation also changes, from just “What percentage was the CPU at?” to “At the moment the audio cut out, what was the next audio waiting for?”

Waiting on Data and Locks

Suppose the processing that prepares the audio data is waiting for a file read to complete. The same applies when it waits for a lock held by other processing within the app. The waiting processing itself uses little CPU, but on the device side playback continues and the remaining audio dwindles. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Playback continues even during waits that use no CPU
    accDescr: While the audio processing waits for data or a lock, it uses no CPU, but playback continues and what is left decreases, and if the refill is late the buffer can run out.
    A["Audio processing waits for data"] --> B["That processing uses no CPU"]
    B --> C["Playback continues meanwhile"]
    C --> D["Late refill means running dry"]

Figure 5: Not using the CPU is not the same as having the necessary work done.

DPCs, ISRs, and the Audio Thread

An ISR is the processing that responds to an interrupt from a device. A DPC is a mechanism that defers the remaining work so that interrupt handling can be kept short. Ordinary DPCs run before ordinary threads on the same logical CPU, and while ordinary DPCs or ISRs are running, that logical CPU cannot run ordinary threads. Introduction to DPCs, CPU Analysis

Even if the CPU as a whole has headroom, supply can be delayed if these run long or occur frequently on the CPU the audio processing needs. Microsoft’s performance-analysis material for audio and video lists long DPCs/ISRs from network, storage, graphics and other drivers among the candidate causes of dropouts. Examining only the device that produces the sound is not necessarily enough. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: When responding to devices delays audio execution
    accDescr: When ordinary DPCs or ISRs run long on the CPU the audio processing needs, thread execution is delayed, which can affect the refill deadline.
    A["DPC/ISR on the same CPU"] -->|"if they run long"| B["Audio execution is held up"]
    B --> C["Next refill is delayed"]
    C --> D["Dropout once it runs out"]

Figure 6: Processing for devices other than the one producing the sound can also indirectly affect the audio refill.

No common line can be drawn of the form “if DPCs stay under so many microseconds, no PC will ever have dropouts.” The warning thresholds in the performance assessment material are values under that assessment’s conditions, and they are not to be taken as a safety standard detached from the actual refill deadline and buffer headroom. Results for the Streaming Media Performance Assessment

Buffer Size and Playback Latency

Under the same conditions, holding more audio ahead makes it easier to absorb temporary refill delays, but newly produced audio then waits behind the audio already buffered. A wait that is acceptable when you are just listening to music becomes a noticeable gap between action and sound when you play a keyboard, or when you process your voice from a microphone and listen to it yourself. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Buffer headroom and delayed response
    accDescr: Holding more audio ahead makes temporary refill delays easier to absorb, but it also increases the wait before new audio is played.
    A["Hold more audio ahead"] --> B["Absorbs late refills better"]
    B -->|"in exchange"| C["New audio waits behind"]
    C --> D["Action-to-sound delay grows"]

Figure 7: Enlarging the buffer is an adjustment that buys headroom at the cost of responsiveness.

It is neither “smaller means higher performance” nor “bigger is the right answer.” Keep the responsiveness you need while securing enough headroom to avoid dropouts.

Enlarging the buffer creates headroom against temporary supply delays. If the average supply itself cannot keep up with consumption, enlarging a finite buffer only lengthens the time until it runs out, and it does not resolve a device disconnecting either. Nor is this a recommendation that using exclusive mode solves everything. Exclusive-Mode Streams

480 Frames of Audio at 48 kHz

A PCM frame is the unit that groups the samples of all channels played at the same instant. Being stereo does not mean you double the frame count to calculate the time. The length of audio a frame count represents is found as “frame count ÷ sample rate,” so 480 frames at 48 kHz is 480 ÷ 48000 seconds, that is, 10 milliseconds. Increasing the frame count while staying at 48 kHz also lengthens the time of audio that can be held. Rendering a Stream

This time is separate from the total latency from pressing a key to hearing the sound, because the app, the driver, the device, and other buffers and processing also take time. Read a DAW’s setting values, too, after checking their unit and which buffer they refer to. Low Latency Audio

flowchart TB
    accTitle: Time derived from the frame count versus total latency
    accDescr: The 10 milliseconds from dividing 480 frames by 48000 is the time the buffer represents, and adding the processing in the app, driver, device and so on gives the total latency from key to sound.
    A["480 ÷ 48000"] --> B["10 ms the buffer represents"]
    B -->|"plus other processing"| C["Total key-to-sound latency"]

Figure 8: The time derived from the frame count is only part of the total latency.

Comparing Reproduction Conditions

First narrow down the combination that reproduces the problem, and move on to detailed recording only if necessary. What follows is a procedure for confirming the cause, not a list of fixes in which every setting change is made all at once.

Save your work, wait until any live meetings or recording sessions are over, and then try this at a volume that is comfortable for your ears. Note down the original output device, audio enhancements, buffer values and so on, so that you can put them back. Skip any item for which no setting is provided, and do not change the registry or anything similar to make a setting appear.

1. Decide on the same short audio source and observation period, and confirm that the problem reproduces under the original conditions.

   Record the Windows version, the app name and version, the output device, the connection type and the driver version. Also note the time, the operation and the number of times dropouts occurred. If it does not reproduce under the original conditions, do not conclude that it has improved; go back to identifying the conditions under which it reproduces.

2. Choose one comparison from the following table, and play with only that condition changed.

   Condition to compare	What to look for
   A locally saved audio source versus playback over the network	Whether it happens only over the network. If the format or processing path differs even for the same content, record that too.
   The same audio source played in a different app	Whether it is concentrated in a particular app.
   Bluetooth or similar output versus built-in or wired output	Whether it is concentrated in a particular output path.
   Audio enhancements on versus off	Whether it changes in combination with effects processing.
   The current buffer in a DAW or similar versus one step larger	Whether more headroom held in advance changes it. Whether the delay from action to sound is also acceptable.

3. When comparing audio enhancements, temporarily turn the setting off for the output in question.

   In Windows, go to “Settings” → “System” → “Sound,” select the output in question, and, where available, turn off “Audio enhancements.” If what is displayed or which items exist differs, check the guidance for that version and device. Fix distorted or crackling audio in Windows

4. Change the setting back and try again with the same audio source and observation period.

   Line up the results for “original conditions,” “one condition changed” and “changed back.” Return any change that had no effect to its original state before moving on to another comparison. If you keep changing combinations of settings, you lose track of what made the difference.

5. If you try changing the driver, do so only after confirming the official distribution and how to recover.

   Use Windows Update or the device manufacturer’s official distribution, and record the versions and settings before and after the change. Confirm in advance that you can roll back, and on a managed PC, consult your administrator. Do not treat it as solved just because playback worked once right after the update; check under the same reproduction conditions. Fix distorted or crackling audio in Windows

The result you want is a record that ties the symptom to conditions, such as “it reproduces in this app when using this output.” Even if you find a setting that improves things, keep that separate from establishing the cause.

flowchart TB
    accTitle: Comparing by changing one condition and changing it back
    accDescr: Confirm reproduction with the same audio source, change one condition such as the app or the output, and also record the result after changing it back.
    A["Play the original combination"] --> B["Play with one change"]
    B --> C["Play after changing it back"]
    C --> D["Note dropout conditions and time"]

Figure 9: Rather than a one-time improvement, confirm that the conditions and the symptom correspond repeatedly.

Reproducibility Before and After a Change

“The symptom was suppressed,” “the conditions were narrowed down,” and “the root cause was identified” are different milestones. Record your conclusion to match the extent of what you could observe.

flowchart TB
    accTitle: Three results that point to a link with a condition
    accDescr: If it reproduces under the original conditions, improves when one condition is changed, and reproduces when changed back, that is a clue pointing to a link with that condition, but it is kept separate from establishing the cause.
    A["Reproduces as originally set"] --> B["Improves with one change"]
    B --> C["Reproduces when changed back"]
    C --> D["Clue linking that condition"]

Figure 10: Even when all three line up, what you learn goes only as far as a clue to a link.

Low CPU usage is not evidence that the audio deadline was met. At the same time, the mere fact that a dropout occurred does not show that a late refill was the root cause. Compare the audio source, the app’s processing, effects, the output path and so on, and judge within the scope of what you observed. Fix distorted or crackling audio in Windows

When you adopt a provisional workaround, keep a record of the original settings, what was changed, the observation period, whether the problem recurred, and the latency you can tolerate. If the root cause has not been established, record that as well.

Recording Dropouts with WPR

Do this when comparing conditions alone does not narrow things down, or when you are examining processing on the driver side. WPR is the tool for recording, and WPA is the tool for analyzing the saved timeline. Prepare the Windows Performance Toolkit, the permissions needed for recording, and a location to save the ETL file. If the tools have to be installed on a managed PC for recording, ask your administrator. Check the display names and available profiles in the version you installed. Windows Performance Recorder

An ETL file can contain process names, file paths and the like. Before recording, check your organization’s rules and who the file will be shared with, and do not attach it as-is in a public place. If another recording session is running, do not stop it on your own; check with the person responsible. WPR How-to Topics

1. Open “More Options” in WPR and choose a recording profile that suits your purpose.

   The built-in profiles include “Audio glitches” and “CPU usage.” Choose settings that let you examine audio discontinuities and CPU activity. Check the available profiles, display names and what they collect in the version you installed, and do not set it up to record every type for a long time. Built-in Recording Profiles

2. Start recording before you reproduce the dropout.

   If a prompt appears asking to stop an existing recording, do not proceed; cancel the start and check with the person responsible. Keep the conditions the same as without recording, and allow for the possibility that the load of the recording itself changes the symptom. WPR How-to Topics

3. Play under the conditions you found in the comparison, and note the time and the operation when the audio dropped out.

   Include a little trouble-free time before and after the symptom as well. If the problem did not reproduce during a recording, state that fact clearly for that recording, and do not treat it as one that captured the cause.

4. After reproducing it, end the recording with “Save” and save the ETL file.

   “Cancel” does not save it. Note the save location, the reproduction conditions, whether it was recorded, and whether there was a dropped-events warning. In a recording with dropped events, do not judge the spans you cannot see to be normal. WPR How-to Topics

Once you have the ETL file and notes on the time, operation and conditions of the dropout, you are ready to cross-check them in WPA. Saving a recording does not by itself mean the needed events were captured. Check the contents in the next section, “Execution and Waits Around a Dropout.”

flowchart TB
    accTitle: Taking a short recording that includes a dropout
    accDescr: Start recording in WPR, reproduce the symptom and note the time, then stop and save, and examine the recording in WPA.
    A["Start recording in WPR"] --> B["Reproduce under same conditions"]
    B --> C["Note time and action, then save"]
    C --> D["Zoom in around it in WPA"]

Figure 11: CPU usage viewed after the symptom has ended is not enough; you need a recording of the span in which the symptom occurred.

Execution and Waits Around a Dropout

Have the saved ETL file and your notes on the reproduction time ready. What follows is a starting point for investigation in WPA. If you need detailed analysis involving stacks and symbols, handle the recording with care and ask an administrator or developer.

1. Open the ETL in WPA and, based on the audio events that were captured and the reproduction time, zoom in on the span before and after the dropout.

   Keep a span without the symptom for comparison as well. Do not look only at a ranking of maximum values; align to the same time range and compare.

2. In the same range, check “DPC/ISR” and “CPU Usage (Precise).”

   If the data you need is not there, check whether the profile can capture it and go back to recording with WPR. The absence of a record is not the same as the absence of a problem. CPU Analysis, Built-in Recording Profiles

3. Distinguish whether the audio-related thread was ready to run but waiting its turn, or was waiting for data or something else.

   If the former, cross-check whether DPCs/ISRs or the like were running for a long time on the relevant logical CPU. If the latter, trace what released the wait using the events and stacks you captured. Because a running thread can also be interrupted, do not narrow your view to Ready time alone; overlay the DPC/ISR spans as well. CPU Analysis

4. Record the timing correspondence with the dropout, the CPU involved, and the results of changing conditions together.

   Do not settle on a particular device or driver as the cause from the module name of a long DPC/ISR alone. You may be looking at a large value from a different time, or at a shared component that multiple devices go through.

flowchart TB
    accTitle: Examining how the thread waited during the dropout
    accDescr: Zoom in on the span around the dropout and look at the audio thread's state. If it was ready and waiting its turn, cross-check with DPCs and ISRs on the same CPU, and if it was waiting for data or the like, trace the processing that released the wait.
    A["Zoom in around the dropout"] --> B{"Thread state"}
    B -->|"waiting its turn"| C["DPC/ISR"]
    B -->|"waiting for data"| D["What released the wait"]

Figure 12: Instead of picking out only the maximum values, read them overlaid on the span in which the audio processing was needed.

If you cannot pin down the cause, hand over the investigation as unresolved. Include the OS, app, device and driver versions, the reproduction steps, the results before and after changes, the time of occurrence, the collection profile, and whether there was a dropped-events warning. Share the ETL only with the people responsible for the investigation, in line with your organization’s rules.

Reading Ahead in Audio Apps

If you build an audio app yourself, design it so that the processing that fills the next buffer meets its deadline every time. WASAPI offers a way to receive, as an event, the moment when a buffer can be processed. Exclusive-Mode Streams

MMCSS is a mechanism that allocates CPU resources to the threads of time-sensitive multimedia processing. It has no function for preparing data from disk in advance or for eliminating lock waits. Even when you use MMCSS for allocation, you still need a separate design for preparing data and reducing waits. Multimedia Class Scheduler Service

flowchart TB
    accTitle: What MMCSS takes care of
    accDescr: MMCSS allocates CPU resources to the threads of time-sensitive processing, but preparing data and reducing lock waits are handled by a separate design.
    M["MMCSS: allocates CPU resources"] -.->|"needed separately"| D["Preparing data, reducing waits"]

Figure 13: Allocating CPU resources and designing for data to arrive in time are separate jobs.

The design principle is to separate the processing that reads from files or the network from the processing that hands over audio. Do preparation whose duration is hard to predict ahead of time, and use preallocated buffers for the handoff. On the audio side, structure things so that it does not have to wait for UI responses, long locks, or synchronous log writes.

flowchart TB
    accTitle: Separating hard-to-predict preparation from audio supply
    accDescr: A design that does reading and similar work in an advance stage and passes the prepared data to the audio processing through a buffer, reducing long waits just before the deadline.
    A["Prepare data in advance"] --> B["Preallocated handoff area"]
    B --> C["Audio stage passes needed data"]
    C --> D["Supply to the audio output"]

Figure 14: Take time-consuming work out of the moments just before audio is handed over.

If the preparation side stalls for a long time, the stock runs out even with this separation. Record not only the average processing time but also the occasions when long processing or waits occurred and the number of times supply failed, using a method that does not interfere with the audio processing. Check the buffer size and period actually chosen through the API or driver, and do not assume that the values you specified were adopted as-is. Rendering a Stream, Low Latency Audio

Both the numerical examples and the design examples are for explanation; they are neither recommended settings for any particular device nor a guarantee that dropouts will not occur in any given environment.

The Effect of Realtime Priority

We do not recommend, across the board, that users change the whole player to “Realtime” priority. It risks interfering with other important processing, and raising an ordinary thread’s priority does not resolve DPCs/ISRs or waits on data and locks. In development, use mechanisms such as MMCSS and a design that keeps long waits out of the audio supply. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Waits that remain even with realtime priority
    accDescr: Even with the player at realtime priority, ordinary threads cannot get ahead of DPCs and ISRs on the same CPU, waits on data and locks remain, and there is also a risk of interfering with other important processing.
    A["Player set to realtime priority"] --> B["Cannot get ahead of DPC/ISR"]
    B --> C["Data and lock waits remain"]
    C --> D["Risk of blocking other work"]

Figure 15: Even with a higher priority, the waits that delay the audio refill remain.

Related Articles

• Windows “Processor Scheduling” and the Background Services Setting
• Isolating a Windows Disk at 100% Safely
• Why Is RDP Sluggish on a Fast Connection?

References

• Microsoft Learn, Rendering a Stream. Supplying the playback buffer, the remaining amount, the actual buffer size, and the definition of a PCM frame.
• Microsoft Learn, Exclusive-Mode Streams. The timing of buffer supply and audio glitches, the trade-off with latency, and event-driven supply. This is not a blanket recommendation of exclusive mode itself.
• Microsoft Learn, Low Latency Audio. The Windows audio path, buffers, devices and effects processing in relation to latency, and the trade-offs of low latency.
• Microsoft Learn, CPU Analysis. Logical CPUs, thread Ready/Waiting states, the relationship between DPC/ISR and thread execution, and CPU analysis in WPA.
• Microsoft Learn, Introduction to DPCs. The mechanism that keeps interrupt handling short and defers the remaining work to a DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Long and frequent DPCs/ISRs, insufficient data supply, and audio glitches. The assessment’s warning thresholds are not generalized into a safety standard for all devices.
• Microsoft Support, Fix distorted or crackling audio in Windows. Checking audio enhancements, formats, drivers and the like.
• Microsoft Learn, Windows Performance Recorder. ETW recording, analysis with WPA, and using the Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options in WPR and built-in profiles such as Audio glitches and CPU usage.
• Microsoft Learn, WPR How-to Topics. Starting a recording and saving it with Save, conflicts with existing sessions, and cautions about personal information and dropped events.
• Microsoft Learn, Multimedia Class Scheduler Service. Allocating CPU resources to time-sensitive multimedia processing.
• Microsoft Learn, Scheduling Priorities. Process and thread priorities, and cautions about realtime priority.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These are topic pages close to this theme. Starting from the article, you can go on to related services and other articles.

Services Connected to This Topic

This article leads to the following service pages. Start from the entry point closest to your situation.

Frequently Asked Questions

Questions commonly asked at the time of consultation about the topic of this article.

Why does audio drop out when CPU usage is only about 10%?

With audio, the next data has to be refilled by a deadline, namely before the data currently playing runs out. Even when overall CPU usage is low, the refill can miss it if the audio processing could not run at that moment or was waiting for the data it needed. Not every dropout has this cause, so comparisons that change the output device or the app are also needed.

Will a larger audio buffer fix dropouts?

When the refill is temporarily late, a larger buffer can sometimes absorb it. However, the wait before the buffered audio is played also grows. It is not a setting that goes as far as resolving a sustained lack of processing capacity or a device disconnecting. In apps and drivers that let you change it, note the original value and compare one step at a time.

How many milliseconds of audio are 480 frames at 48 kHz?

It is 480 ÷ 48000 seconds, so 10 milliseconds' worth. One PCM frame is the unit that groups the samples of all channels at the same instant. This value is the length of audio that the frame count represents, not the total latency including the device and the app.

Is a driver with long DPC or ISR execution times the culprit behind dropouts?

It is a candidate, but a ranking by execution time alone cannot settle it. Cross-check the span in which the dropout occurred against the audio thread's waits and DPC/ISR execution on the same CPU. Do not conclude from the module name alone that a particular device or driver is defective; also check the results of changing the reproduction conditions.

Will setting the player to realtime priority help?

We do not recommend it across the board. Raising an ordinary thread's priority does not let it get ahead of ordinary DPCs or ISRs on the same CPU, and waits on data or locks do not go away either. Developers use mechanisms such as MMCSS and a design that brings in no waits, and users first compare reproduction conditions and output paths.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and bug investigation, with particular strength in projects where existing assets remain and in investigating failures whose cause is hard to see.