Why Does Audio Drop Out When CPU Usage Is Low? — Thinking in Terms of Buffers and Deadlines

You are listening to music and every so often it cuts out with a pop. Open Task Manager and CPU usage sits around 10%. Video keeps playing, and the mouse moves normally.

You want to ask, “with all this headroom, is playing audio really too much to expect?”

But what audio needs is not only the ability to get a lot of work done quickly. It also needs the next stretch of sound to be ready before what is playing now runs out. This article follows that late refill, the mechanism behind a typical dropout.¹

We start from the scene of playing music on a PC. Sections 1 to 4 finish the discussion of the mechanism, and section 5 onward collects the investigation methods. The assumption throughout is audio output on Windows 11, and the numbers are assumptions used for explanation.

1. Audio Plays While a Little of What Comes Next Is Held in Reserve

A music file stored on the PC does not make the speakers play just by sitting there. The playback app prepares the audio data and delivers it, through Windows and the driver, to the device that produces the sound. In the usual shared mode, the Windows audio engine mixes several streams together and applies effects along the way.²

If audio were handed over one piece at a time exactly when it was needed, the slightest delay in processing would show up directly in playback. So a little of what will be played next is held in reserve in advance. That temporary holding place is the buffer. While playback proceeds on the device side, the app and the audio processing refill it with the next data.³

flowchart TB
    accTitle: Buffer a little sound ahead, then play it
    accDescr: The flow of refilling the buffer with prepared audio data and preparing the next data while playback proceeds on the device side.
    A["Prepare the next audio data"] --> B["Refill the buffer"]
    B --> C["Play the buffered audio"]
    C -.->|"Before the rest runs out"| A

Figure 1: To keep playback going, the refill has to keep up with the side consuming the audio.

Say the buffer currently holds 10 milliseconds of audio. If the next refill lands 8 milliseconds from now, it connects while some is still left. But if nothing arrives until 12 milliseconds from now, the stock runs out at the 10 millisecond mark.

flowchart TB
    accTitle: The same 10 milliseconds left, a different result depending on when the refill lands
    accDescr: As an assumption used for explanation, it shows that for 10 milliseconds of remaining playback data a refill 8 milliseconds later arrives in time, while one 12 milliseconds later arrives after the data is used up.
    A["10 milliseconds left right now"] --> B["Refill 8 ms later"]
    B --> C["Connects while some is left"]
    A --> D["Refill 12 ms later"]
    D --> E["Out of stock at 10 ms"]

Figure 2: A simplified example in terms of time. What matters is not only whether the refill happened, but when.

Running out because the supply of required audio data does not arrive in time is an underrun. It leads to dropouts, clicks, and similar artifacts. Even if the data shows up late, a gap that has already been heard cannot be filled in afterward.¹

Audio playback is work where “it computed eventually” is not enough; what it needs is “it was ready by the time it had to play.”

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

2. Why the Refill Is Late Even When the CPU Is Idle

Hearing all this, the natural response is, “then if the CPU is idle, why not refill early?”

But the CPU usage number is not a count of audio deadlines met. How busy the whole CPU was over some span of time and whether the short piece of work that refills the audio got to run at the moment it was needed are two different things. A low overall load is no guarantee that the audio work gets its turn immediately every time.⁴

In terms of the earlier example, even if there is headroom for most of a second, a single stretch where the refill cannot happen for 12 milliseconds exhausts the 10 milliseconds of audio that were left. Headroom remaining later in the second does not rescue that one late arrival.

Not Slow Computation, but Waiting for a Chance to Run

Suppose the code that prepares the audio data is waiting for a file read to finish. Or it may be waiting on a lock held by another piece of work inside the app. While it waits, that code itself uses little CPU. The audio already playing keeps draining all the same. A late data supply and a waiting thread happen independently of using up the CPU.⁵⁴

flowchart TB
    accTitle: Playback advances even during wait time that uses no CPU
    accDescr: Playback advances while the audio processing waits on data or a lock, so the buffer can run dry with CPU usage still low.
    A["Audio processing waits for data"] --> B["That work uses no CPU"]
    A --> C["Playback continues and what is left shrinks"]
    C --> D["A late refill means running out"]

Figure 3: “Not using the CPU” is not the same as “the necessary work is done.”

Devices That Seem Unrelated to Audio Can Hold It Up Too

There is a second case, where the turn does not come around on the Windows side.

When a notification arrives from a network device or the like, Windows runs code that handles the interrupt. The short first piece of that work is the ISR, and the mechanism that defers the rest of the work is the DPC. While an ordinary DPC or ISR is running, that logical CPU cannot run ordinary threads. Audio processing is subject to this as well.⁶⁴

When such work runs long or runs often on the CPU where the audio needs to run, the opportunity to refill the audio is pushed back. Microsoft’s performance analysis material for audio and video also explains that long DPCs and ISRs from network, storage, graphics, and other drivers can cause audio glitches.⁵

flowchart TB
    accTitle: When responding to a device delays the execution of audio
    accDescr: When an ordinary DPC or ISR runs long on the CPU the audio processing needs, thread execution is delayed and the refill deadline can be affected.
    A["DPC or ISR on the same CPU"] -->|"When it runs long"| B["Audio execution is held up"]
    B --> C["The next refill is late"]
    C --> D["A dropout once what is left runs out"]

Figure 4: Not only the device producing the sound; work for other devices can have an indirect effect.

In other words, a dropout is not only “the CPU is too slow to finish the computation.” The computation cannot start, or the data it needs does not arrive. That wait, too, is time eaten out of the audio’s deadline.

3. So Why Not Just Hold a Lot of Audio in Reserve?

If the refill is a little late, it seems sensible to keep enough stock to absorb that delay. This is exactly the reasoning that leads to making the audio buffer larger.

Under the same conditions, holding more audio ahead of time makes short refill delays easier to ride out. But now newly produced audio waits behind the audio already held in reserve.¹²

If you are only listening to music, waiting a moment after pressing play may not bother you. When you play a keyboard connected to the PC, or process your own voice from a microphone and listen to it yourself, that wait becomes a gap between the action and the sound.

flowchart TB
    accTitle: Buffer headroom and slower response
    accDescr: Holding more audio ahead of time makes temporary refill delays easier to absorb, while the wait before new audio is played also grows.
    A["Hold more audio ahead of time"] --> B["Refill delays are easier to absorb"]
    A --> C["New audio waits behind"]
    C --> D["More delay from action to sound"]

Figure 5: Increasing the buffer is an adjustment that buys headroom in exchange for responsiveness.

The buffer settings of 128, 256, and 512 found in music production software relate to this time as well. In PCM, the unit that groups the samples of all channels at the same instant is called a frame. At 48 kHz, 480 frames is 480 divided by 48000 seconds, that is, 10 milliseconds of audio. At the same sample rate, the more frames, the longer the stretch of audio they hold.³

What was counted here is the length of audio that buffer represents. In practice there is also processing in the app, the driver, and the device, so keep it separate from the total latency between pressing a key and hearing the note. Nor does every app on Windows share one common buffer setting; the sizes you can choose also vary with the device and the driver.²

So smaller is not higher performance, and larger is not the right answer either. The adjustment is to keep the responsiveness you need while taking enough headroom to avoid dropouts.

4. What Audio Needs Is Meeting Deadlines, Not Average Speed

Back to the original question.

Audio drops out at low CPU usage because having headroom in overall processing capacity and delivering the next stretch of sound on time are two different things.

Audio plays from a small amount held in reserve. That stock is refilled before it is used up. A single late refill can be enough to cause a gap, and increasing the stock adds headroom but also lengthens the time before new audio is heard.

That is the core of the mechanism. The question you ask when investigating changes too, from “what percentage was the CPU at” to “at the instant the audio cut out, what was the next stretch of sound waiting for.” From here on is the investigation part, for narrowing down an actual symptom.

5. Investigation: First, Find Out Which Combination Drops Out

A pop you heard does not by itself establish the underrun described so far. The source material itself, the app’s processing, audio effects, the output device, and other problems produce similar symptoms. Microsoft’s troubleshooting material also lists audio enhancements, the format, and drivers among the things to check.⁷

Do not change settings in bulk at the start. Play the same short source for about the same length of time and compare the differences one at a time. Do this outside a live meeting or a recording session, after saving your work, and at a volume that is easy on your ears.

In this order, the one-line complaint “the audio cuts out” can be made concrete enough to say “it cuts out only in this app, when this output is used.” Reverting each change and trying again also makes it easier to tell whether the symptom simply happened not to appear.

flowchart TB
    accTitle: Comparison that changes one condition and then reverts it
    accDescr: Confirm the reproduction with the same source, change one condition such as the app or the output, and record the result after reverting as well.
    A["Play with the original combination"] --> B["Change one condition and play"]
    B --> C["Revert and play"]
    C --> D["Record the conditions and times that dropped out"]

Figure 6: Rather than one improvement, confirm that the condition and the symptom line up repeatedly.

Note that changing the output also changes the driver, the buffers, and more. “It does not cut out over a wired connection” is a clue for investigating the output path, but on its own it does not establish the wireless radio as the cause. Likewise, an improvement from a larger buffer is a clue that extra time headroom helped; it does not prove a defect in a particular driver.

To compare audio enhancements, select the output in question under Settings > System > Sound in Windows, and where it is available turn Audio enhancements off and try again. Note the original setting, and revert it if it makes no difference. Obtain drivers from Windows Update or the device manufacturer’s official distribution, and record the versions before and after the change.⁷

6. Investigation: Record the Instant of the Dropout and Zoom In

When comparing conditions does not narrow things down, or when you suspect processing on the driver side, record what happens over a short span of time. Windows Performance Recorder (WPR) takes the recording, and Windows Performance Analyzer (WPA) is the tool for examining the recorded timeline in detail.⁸

Start Recording Before You Reproduce It

On a machine where the Windows Performance Toolkit is installed, open More Options in the WPR window. The built-in profiles include Audio glitches and CPU usage. Centering on the former, select a recording that lets you examine audio discontinuities together with CPU activity. Check the available profiles and their display names in the version you installed.⁹

Start the recording, then play audio under the conditions you found earlier. Note the times of the dropouts and what you were doing, and after reproducing the symptom end the recording with Save to write the ETL file. Cancel does not save it. Including a little of a clean stretch gives you something to compare against. If you are prompted to stop an existing recording, cancel the start and check with the person responsible, so that another investigation is not interrupted.¹⁰

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

Figure 7: Keep the span in which the symptom occurred, not the CPU usage after it was over.

An ETL file can contain process names, file paths, and similar, so follow your organization’s rules and share it only with the people who need it. Recording may require privileges or additional tools; on a company PC, ask an administrator. Because the load of recording itself may change the symptom, note whether a recording was running. Prefer a short recording matched to your goal over a long one with every provider enabled. In a recording that reports dropped events, do not judge the spans you cannot see to be healthy.¹⁰

What Happened at the Same Time, Rather Than a Ranking of Big Numbers

In WPA, zoom into the area around the dropout using whatever audio events were captured and the times you noted. Over that same time range, check DPC/ISR and CPU Usage (Precise), which shows thread execution and waits. If that data is missing, check whether the profile captures the events you need and record again. An absence of records is not the same as an absence of a problem.⁴⁹

The starting point is to see whether the audio-related thread was ready to run but waiting for its turn, or could not run because it was waiting on data or something similar. In the first case, look for DPCs, ISRs, and the like running long on that CPU. In the second, trace what released the wait, using whatever records and stacks are available. Because a running thread can also be interrupted, do not narrow to Ready time alone; overlay the spans in which DPCs and ISRs ran.⁴

flowchart TB
    accTitle: Examine how it waited during the dropout span
    accDescr: For the audio thread in the span of interest, separate waiting while ready to run from waiting on data or similar, and cross-check the corresponding records.
    A["The same span around the dropout"] --> B["Ready to run but waiting its turn"]
    A --> C["Waiting on data or similar"]
    B --> D["Cross-check work on the same CPU"]
    C --> E["Trace what released the wait"]

Figure 8: Do not pick out the maximum values alone; read them overlaid on the span in which the audio processing was needed.

Even when you find a long DPC or ISR, do not look at the module name and immediately decide “this driver is the culprit.” You may be looking at a large value from a different time, or at a shared component that several devices go through. Combine the correspondence in time with the dropout, the CPUs involved, and the results of changing conditions, and ask the device manufacturer to investigate if needed.

Nor can you draw a universal line such as “a DPC under so many microseconds never causes a dropout on any PC.” The warning thresholds in the documentation are conditional on that assessment. Do not use them as a pass/fail test detached from the actual refill deadline and the buffer headroom.⁵

7. For Developers: Do Not Bring Long Waits into the Code That Hands Off Audio

When you build an audio app yourself, the starting point is the same. The code that fills the next buffer has to meet every deadline.

WASAPI offers a way to receive, as an event, the timing at which a buffer can be processed. MMCSS, in turn, makes it easier to give CPU time to threads doing time-constrained multimedia work. Neither is magic that removes waits, however. MMCSS will not prepare the audio data from disk ahead of time for you either.¹¹¹

The design for that is to separate the code that reads from files or the network from the code that hands audio off. Do the work whose timing is hard to predict in advance, and use a pre-allocated buffer for the handoff. On the audio side, shape things so there is no need to wait on a UI response, a long lock, a synchronous log write, or the like. This is a design policy for decoupling data waits from the deadline.

flowchart TB
    accTitle: Separate hard-to-predict preparation from the audio supply
    accDescr: A design that does reads and similar work ahead of time and passes the prepared data to the audio processing through a buffer, reducing long waits just before the deadline.
    A["Prepare data in work done ahead of time"] --> B["Pre-allocated handoff area"]
    B --> C["Hand the audio processing what it needs"]
    C --> D["Supply the audio output destination"]

Figure 9: The point is not to eliminate slow work, but to move it out of the moment just before the audio is handed off.

Even with that separation, the stock runs out if the preparation side stalls for long. Beyond the average processing time, record the occasions on which processing or a wait ran long and the number of times the supply failed, in a way that does not disturb the audio processing. Check the buffer size and period actually chosen through the API or the driver, and do not assume that “the value I specified was adopted as is.”³²

Avoid recommending that users set the whole player to realtime priority. It risks obstructing other important work, and raising an ordinary thread’s priority does not resolve DPCs, ISRs, or data waits.¹²⁴

8. Summary: Low CPU Usage Is Not Evidence That the Audio Deadline Was Met

There are three axes for thinking about dropouts: hold audio in reserve, refill it before it is used up, and a late refill means a gap. Even at low CPU usage, a wait at the moment it matters can make the refill late.

Start by comparing apps and outputs with the same source, and if that still does not explain it, record the span of the dropout. Moving from “why, when the CPU has headroom” to “what was it waiting for at that instant” brings the next thing to examine into view.

Related Articles

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

References

Related Articles

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

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

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

Audio has a deadline: the next data has to be refilled before the data now playing is used up. Even when overall CPU usage is low, the refill can miss that deadline if the audio processing could not run at that instant or was waiting for the data it needed. Not every dropout has this cause, so you also need comparisons that change the output device and the app.

Will making the audio buffer larger fix dropouts?

When the refill is temporarily late, a larger buffer can absorb it. But the wait before the stockpiled audio is played also grows. It is not a setting that resolves a sustained shortfall in processing capacity or a device disconnecting. In apps and drivers where it can be changed, note the original value and compare one step at a time.

At 48 kHz, how many milliseconds of audio is 480 frames?

It is 480 divided by 48000 seconds, so 10 milliseconds. 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 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 a dropout?

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

Does setting the player to realtime priority improve things?

Not as a blanket recommendation. Raising an ordinary thread's priority cannot get ahead of ordinary DPCs and ISRs on the same CPU, and it does not remove waits on data or locks. Developers should use mechanisms such as MMCSS together with a design that brings no waits into the audio path, while users should 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 investigations into failures that are difficult to reproduce.