How to Fix Audio Crackling in Windows 11: DPC Latency and Driver Troubleshooting

What the author reported​

Dey says the pops showed up in OBS recordings, in DAW sessions and on Discord calls. They also appeared under an ASIO load with a dedicated external audio interface.

His observations were:

• LatencyMon kept going red. This happened whether or not the external interface was plugged in.
• The onboard Realtek chip behaved the same way. That ruled out his first suspect, the USB audio path.
• Testing with and without a WLAN adapter changed nothing.

He then cut background activity in four steps:

1. He uninstalled Asus Armoury Crate and its leftover services.
2. He ran the third-party Win11Debloat utility.
3. He stopped some background processes that kept the SSD busy.
4. He disabled CPU core parking with a custom power plan from the Quick CPU app.

He says LatencyMon then stayed mostly green with the occasional yellow, and the crackling stopped.

Treat that as one person's account. He gave no LatencyMon report, no named offending driver, and no before-and-after numbers. He also made every change at once, so nothing isolates the cause.

Why a fast PC can still crackle​

Real-time audio depends on deadlines, not on total CPU power. Windows drivers do urgent work through interrupts and deferred procedure calls (DPCs). Prism Sound's tech notes explain that ordinary Windows processes, such as DAWs or ASIO drivers, are locked out whenever a DPC needs to run. If that lockout lasts longer than the audio buffer, the app misses its deadline and you hear a click or gap. Prism's rule of thumb is that DPC latency should be consistently well below 1ms (1000µs) to avoid audio glitches.

Microsoft's own documentation for Windows MIDI Services gives a concrete scale. A 128-sample buffer at 48 kHz holds about 2.7 milliseconds of audio. A larger buffer gives the app more slack but adds latency, which matters for live monitoring.

Why one red graph isn't a diagnosis​

The source article leans on the idea that "too many DPC calls" caused the problem. The evidence doesn't support that simple count.

• Microsoft's DPC guidance says long DPCs are common and often harmless. They matter only when they hold up the audio or MIDI work.
• Microsoft's newer MIDI troubleshooting tool is built on the same idea. It says the DPC check isn't a benchmark. It is meant for when you already hear clicks, pops or dropouts at a buffer size that should be big enough for your project. It also lists which drivers held audio up, and which only ran long without causing a problem.
• The usual suspects are network, storage, graphics, USB and power-management drivers. This is why the GPU brand argument on forums goes nowhere.

Dey's own point that no single culprit stands out is therefore reasonable. But his inference that bloat caused it goes further than the data does. A single driver can cause the problem without there being many calls, and background clutter can be harmless.

A more targeted approach​

Focusrite's DPC troubleshooting guide is a good model. It says to run LatencyMon for at least 15 minutes, with the glitch occurring during the test. Then open the Drivers tab and sort by highest execution time. Focusrite says drivers exceeding 0.500000ms are worth scrutiny in its own scheme, though it's a vendor guideline, not a Microsoft threshold.

A sensible order of tests, most reversible first:

1. Update the basics. Install Windows updates, then chipset, GPU, Wi-Fi and storage drivers, and the BIOS.
2. Plug in and pick a performance power mode. Microsoft's guidance suggests Best performance on a plugged-in laptop.
3. Pause background load. Stop big downloads, cloud sync, backups and virus scans while recording.
4. Isolate the network. Temporarily turn off Wi-Fi and Bluetooth. Focusrite specifically links ndis.sys latency to network activity.
5. Isolate peripherals. Connect the interface directly instead of through a hub, and unplug other USB devices, reconnecting them one at a time.
6. Treat the driver LatencyMon names. Focusrite gives driver-specific steps for ACPI, graphics, storage and USB. For NVIDIA graphics, it suggests trying the Studio driver instead of Game Ready.
7. Try a clean boot. This tells you whether a service or startup app is involved.
8. Raise the buffer size. This is a workaround, not a cure, and it costs latency.

Microsoft's guidance warns against switching off Microsoft Defender, Memory Integrity or virtualization-based security to improve audio. That includes any tuning guide that suggests it.

The core parking claim needs care​

Dey says Windows parks cores "even more aggressively" on laptops, regardless of power source. That is a simplification. Microsoft Learn describes core parking as an engine that decides how many cores a workload needs. It also says processor power profiles are tuned by silicon vendors and advises asking the vendor before changing them.

Unparking cores might help a latency-sensitive workload. But in this story it was bundled with other changes, so it wasn't tested on its own.

The costs he reported​

Dey is upfront about the trade-offs, which are worth repeating:

• Battery life took the biggest hit. Cores that stay awake keep the CPU out of deeper idle states, so idle power draw and temperatures rise.
• Fans spin up more and the chassis runs warmer.
• Removing Armoury Crate removes its features. He lists fan curves, thermal modes, GPU power-saving switches and some keyboard hotkeys.
• Debloat scripts can break things. He warns about the Microsoft Store, Xbox services and Windows Search indexing.

His advice to create a System Restore point before running a debloater is sound. Focusrite's guide also notes that disabling stepping technologies like SpeedStep or Cool'n'Quiet in the BIOS hurts laptop battery life, so he isn't alone in finding this trade-off.

What to take from this​

• Crackling during recording isn't always a hardware fault. Timing delays from drivers and system activity are a well-documented cause.
• A red LatencyMon graph is a clue. It doesn't name a cause until you look at which driver is responsible.
• Dey's bundle of changes worked on his machine. Which of them mattered isn't established, and another Vivobook or a desktop could differ.
• Try the reversible, targeted steps first. Debloating, removing OEM software and changing processor settings are better held back until those fail.
• If the problem persists, a physical fault in the motherboard or the interface's circuitry is still possible, as the article itself acknowledges.

Dey's closing advice is to test with an external interface, trim background processes, or do a clean OS install as first steps. The approach above reaches the same goal more gently, and you will know which fix worked.