Sound crackling on Windows is often a timing problem: a driver briefly “blocks” the CPU from servicing the audio stream on time, causing buffer underruns. DPC latency is the common label for this behavior—when Deferred Procedure Calls (and related interrupt work) run too long, audio can’t be delivered smoothly, so you hear pops, clicks, or crackle. (resplendence.com)
What “DPC latency” actually means in plain terms
Windows is constantly juggling work: network packets, USB devices, graphics, storage, power management, and audio. Some of that work happens at very high priority (interrupt service routines, then deferred procedure calls). If one driver hogs that high-priority time—even for a few milliseconds—the audio engine may miss its deadline to refill the buffer. The result is a tiny gap in the audio stream you perceive as a click, pop, or crackle. (resplendence.com)
This is why you can have a fast CPU and still get crackling: it’s not “average performance,” it’s “worst-case timing.” A single misbehaving driver spike is enough.
How to tell if DPC latency is your problem (not the speakers, not “Windows sound”)
Crackling caused by DPC latency tends to have these patterns:
- It gets worse when the system is under “mixed” load (streaming + downloads, gaming + voice chat, copying files + audio).
- It changes when you toggle certain devices (Wi-Fi, Bluetooth, external USB peripherals).
- It improves if you raise the audio buffer size (more latency, fewer underruns).
- It can show up across multiple apps (browser, media player, DAW), because the bottleneck is below the app.
If crackling only happens in one specific app with one specific setting, it may still be buffer configuration—but widespread system crackle is a strong DPC-latency clue.
Measure it the right way: capture the spikes while you use the PC normally
You don’t fix DPC latency by guessing—you isolate which driver is producing the long high-priority routines.
A practical tool for this is LatencyMon. It’s designed to report high ISR/DPC execution times and often identifies the responsible driver module. Run it while reproducing the crackle (same devices connected, same workload), because idle tests can look “fine” and miss the spikes. (resplendence.com)
What to look at in the report:
- Highest DPC routine execution time and highest ISR routine execution time: big outliers matter more than averages. (resplendence.com)
- Drivers tab: sort by highest execution time; the top offenders are your leads.
- Hard pagefaults can matter, but for classic crackling, the usual culprit is still a driver routine that runs too long at elevated priority. (resplendence.com)
The usual suspects (and why they cause crackling)
DPC-latency crackle is frequently tied to drivers that handle bursty, real-time-ish events:
- Network adapters (Wi-Fi/Ethernet)
Network drivers can generate bursts of interrupts. Bad driver versions, power-saving features, or buggy offload settings can create periodic spikes that starve audio briefly. (A quick test is disabling the adapter to see if crackle stops.) (h30434.www3.hp.com) - GPU and display stack
Graphics drivers can trigger latency spikes, especially with certain driver branches or overlays. Even if your audio is not “through the GPU,” the GPU driver can still steal high-priority time and cause audio underruns. (NVIDIA Developer Forums) - ACPI / power management
Power-saving transitions (CPU throttling, deep sleep states, aggressive device power management) can increase worst-case latency. Many crackling cases improve when power management is relaxed and firmware/drivers are updated. (learn.microsoft.com) - USB controllers and external audio devices
USB audio is sensitive to timing. A noisy USB bus (hubs, too many devices, power saving, or a flaky controller driver) can contribute to dropouts. - Storage drivers
Less common than network/GPU, but storage drivers can appear in reports and still contribute if they create long high-priority routines during I/O bursts.
Fix it systematically: a practical checklist that actually narrows causes
1) Confirm with one “buffer size” change
Before touching drivers, do one reversible test:
- If you’re using an audio interface/DAW, increase buffer size (e.g., 128 → 256 or 512).
- If crackling largely disappears, you’ve confirmed “deadline misses” rather than a damaged speaker or cable.
This doesn’t solve the root cause, but it prevents you from chasing the wrong problem.
2) Update (or roll back) the driver that LatencyMon points to
When LatencyMon lists a driver module as the highest DPC/ISR execution time contributor, do this in order:
- Update that device’s driver from the PC/laptop manufacturer first (especially for laptops), or from the component vendor if appropriate (Intel/AMD/NVIDIA, Realtek, etc.).
- If the issue started after a recent update, roll back to the previous known-good version.
- Re-test under the same workload.
GPU drivers are a common “version-sensitive” area; if your spikes line up with a driver update history, testing one alternate driver branch can be decisive. (NVIDIA Developer Forums)
3) Temporarily disable devices to isolate fast
If you need a fast binary answer, disable one device at a time (Device Manager) and re-test:
- Wi-Fi adapter
- Bluetooth adapter
- Webcam
- Unused audio devices (HDMI audio, virtual audio drivers)
- Any “gaming” virtual network adapters or VPN components
If disabling a device immediately stops crackling, you’ve likely found the driver class responsible.
4) Put Windows on a less aggressive power profile
Timing issues often improve when the system stops downclocking/parking too aggressively:
- Switch to High performance (or the closest available option).
- In advanced power settings, test:
- Minimum processor state higher than default
- USB selective suspend = Disabled (especially for USB audio)
- If your laptop has vendor power modes, test the “performance” mode.
This aligns with common guidance to check CPU throttling and BIOS/firmware when real-time audio is unstable. (learn.microsoft.com)
5) Update BIOS/UEFI and chipset drivers (especially on laptops)
Firmware bugs and chipset-level power management quirks can show up as ACPI-related spikes. BIOS updates often include stability fixes that don’t look audio-related, but can affect latency. (learn.microsoft.com)
If LatencyMon implicates ACPI-related modules frequently, firmware and chipset updates are a high-value next step.
6) Remove “helpers” that hook deep into the system
Some background tools add kernel drivers or frequent high-priority activity:
- Third-party antivirus suites (test by temporarily uninstalling, not just disabling)
- RGB/device control utilities
- Overlay/recording tools
- Virtual audio routing drivers you don’t need
The goal is not “debloating,” but reducing kernel-level contention until the spike source is clear.
7) Clean up the USB path for external interfaces
If you use a USB audio interface:
- Plug it directly into a main USB port (avoid hubs).
- Try a different port (USB controller changes can matter).
- Disable USB power saving as noted above.
- Disconnect other high-traffic USB devices while testing.
8) Don’t rely on outdated “DPC latency checker” tools
Use a tool that measures modern Windows behavior properly and points to drivers; LatencyMon is commonly recommended for that purpose. (resplendence.com)
What “good” looks like after fixes
After a successful change, you should see:
- Crackling reduced or eliminated under the same workload.
- LatencyMon’s worst spikes drop, and the top offender driver changes or stops producing large outliers.
- The system becomes stable at smaller buffer sizes (if you need low-latency audio).
Be aware: there isn’t one universal “safe” number. The lower your buffer, the less tolerance you have for any spikes. LatencyMon notes that threshold choices can be somewhat arbitrary and depend on the latency target. (resplendence.com)
Sources
- LatencyMon (official) – system latency and driver reporting (resplendence.com)
- LatencyMon “Using” guide – interpreting ISR/DPC timing (resplendence.com)
- Sweetwater – Solving DPC Latency Issues (troubleshooting steps) (sweetwater.com)
Why does this matter
Crackling is the audible symptom of missed real-time deadlines; fixing it improves not only audio quality, but overall system responsiveness under load—especially for calls, streaming, and any low-latency audio work.
