Deferred Procedure Calls (DPCs) are a core function of all modern operating systems, including Windows. They control how the system prioritizes and schedules hardware-related tasks. When Windows needs data from a peripheral device—such as a hard drive, network adapter, or graphics card—it issues an Interrupt Service Routine (ISR). If the device cannot provide the requested data immediately, Windows defers part of that work by creating a DPC.
While a DPC is being serviced, certain lower-priority system tasks must wait. On systems running software that depends on uninterrupted real-time data—such as software defined radio applications (SmartSDR using PC Audio, DAX, VAC) or any real-time audio engine—these delays can cause data buffers to overrun or underrun. When that happens, the result may be stuttering, freezing, dropouts, or corrupted audio.
To understand why this occurs, it helps to look briefly at how Windows handles hardware events:
ISR (Interrupt Service Routine): Triggered when a hardware device signals that it needs CPU attention. ISRs should run quickly.
DPC (Deferred Procedure Call): If the ISR can't complete its work immediately, it schedules a DPC to finish the job later. DPCs also run at elevated priority, ahead of most normal tasks.
If either ISRs or DPCs run too long—or if they occur too frequently—they can consume a significant amount of CPU time. This starves time-sensitive processes of the resources they need. In extreme cases, you may experience audio pops, video glitches, frozen mouse movement, or system responsiveness issues.
This is why low DPC latency is critical when running SDR software or any real-time audio system: even momentary delays at the driver or hardware level can disrupt the continuous data flow that these applications require.
From a user’s standpoint, excessive or long-running ISRs and DPCs typically appear as audio stuttering, pops, dropouts, or glitches. This behavior has been a known issue in PC audio for years: if an ISR or DPC delays the audio engine or the application long enough, the audio data cannot reach the hardware in time, and the result is an audible glitch.
For SDR applications such as PowerSDR and DAX, this becomes critical. When DPC latencies exceed 1000 µs (1 ms), audio processing may fall behind. In more severe cases, the DAX audio buffers can become corrupted, resulting in distorted audio, poor or unreliable digital mode decodes, and malformed transmitted signals.
Why ISRs and DPCs Degrade Performance
• The OS cannot prevent them from running.
ISRs are triggered directly by hardware signals, and DPCs are scheduled by those ISRs. Both run at very high priority—DPCs are outranked only by hardware interrupts themselves—so they pre-empt almost everything else on the system, including audio threads.
• They increase as system activity increases.
More system activity generally means more interrupts and more DPCs. Even if each ISR or DPC is short, their combined CPU usage can become high enough to cause audible or visible performance problems. In such cases, it’s often not a single faulty driver; it’s the cumulative load.
• They can affect even powerful systems.
High ISR/DPC latency problems are often not obvious and can occur on PCs with fast CPUs, ample RAM, and low overall utilization. Real-time audio workloads are sensitive to timing, not average CPU load, so a brief but poorly timed spike in ISR or DPC activity can be enough to cause glitches.
It’s important to understand that long-duration DPCs are not caused by a slow CPU, insufficient RAM, or hard drive performance. Instead, DPC latency is determined by the behavior of the hardware peripheral, how that device is integrated into the motherboard, and the quality of its driver. Even a high-end PC can experience severe DPC problems if a poorly designed or misbehaving driver monopolizes the DPC subsystem.
Diagnosing ISR and DPC issues can be challenging because their behavior is highly dependent on each system’s unique combination of hardware, firmware, and drivers. A problem that appears consistently on one machine may not appear at all on another—even if they are nominally similar systems. This is why some PCs run SDR software flawlessly while others exhibit persistent audio glitches or DAX corruption.
Fortunately, several tools exist to analyze DPC latency, and one of the most useful is LatencyMon. LatencyMon can measure ISR and DPC execution time, identify which drivers are responsible for excessive delays, and help pinpoint the root cause of audio and real-time processing issues. For troubleshooting DPC-related problems in SDR environments, it is an invaluable resource.
For information regarding using LatencyMon, refer to the HelpDesk article Using LatencyMon to collect DPC Latency Data for details on where to download LatencyMon and how to run it.
If your PC is experiencing long-duration DPC events above 1000 µs, there are essentially two paths to try to resolve the issue.
The first is to update your system’s BIOS and ensure that all hardware drivers—especially video drivers, motherboard chipset drivers, network drivers, and any other device-specific drivers—are fully up to date. The information provided by LatencyMon can help identify which driver is responsible for the delays.
The second is to shut down applications that are not needed when operating the radio, like browsers and email, which can generate ISRs.
However, it’s important to note that not all DPC issues can be resolved. In some cases, even the latest drivers may still exhibit problematic behavior due to design limitations in the hardware or driver architecture. When this occurs, the underlying DPC latency problem may persist despite updates.