DPCs or Deferred Procedure Calls are a function of all operating systems that cause a PC to wait while it is servicing a request for data from a peripheral device like a hard drive, network adapter or graphics card. If you are operating a software defined radio or any other program that processes real-time audio, such as DAX or VAC, whenever the PC is waiting on a peripheral device to be serviced, all other hardware devices are not serviced, resulting in data buffer overruns which can cause PowerSDR, SmartSDR PC audio or DAX to freeze, stutter or produce corrupted audio. To explain this in more detail a description of how the Windows operating system services hardware requests for data.
When data from a peripheral hardware device is requested by the operating system, an ISR or Interrupt Service Routine is issued. If the device can not immediately service the request, then a DPC is issued and everything else that is happening on the PC must wait until that request for data has been fulfilled. ISRs and DPCs that run too long - or too often - can consume significant amounts of CPU time and cause overall system performance to suffer. They can cause audio and video glitches, mouse freezes, the screen hangs, and any number of other system-wide problems.
From a user's standpoint, problems with long duration or frequent ISRs and DPCs often first show up as audio pops and drops (usually just called 'glitches'). This has long been a known problem for PC audio: problematic ISRs or DPCs can cause enough delays in applications or in the audio engine so that audio data simply fails to get to the hardware in time causing audible glitches. This is exactly what happens to PowerSDR and DAX if DPCs exceed 1000 µS (microseconds). In more severe cases, the DAX audio buffers can become corrupted and that leads to distorted audio which shows up as poor digital mode application decodes and transmissions.
The reason ISRs and DPCs degrade a PC’s performance are:
- The OS has no control over its execution. ISR's are triggered by physical hardware signals from devices to the CPU. DPCs are scheduled by interrupt handlers and run at a priority only exceed by hardware interrupt service routines.
- ISR and DPC activity usually increases with system activity. As a system becomes more active, interrupts and DPCs will generally become more frequent, taking up more CPU time. This can get to the point where they visibly (or audibly) affect system performance. In these cases, no single ISR or DPC routine is the problem - it is their cumulative consumption of CPU time.
- It is rarely obvious that ISRs and DPCs are causing performance problems and can happen on systems with powerful processors with plenty of RAM running at low utilization.
Tracking down Interrupt and DPC problems is further complicated because their behavior is highly dependent on PC hardware configuration and drivers. A problem seen on one system may only be reproducible on that particular system.
Luckily there are a few software tools that will allow you to monitor DPCs and one in particular; LatencyMon will provide a wealth of information on the duration of ISRs and DPCs along with identifying the hardware driver that is responsible for the delays.
For information regarding using LatencyMon for, please 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 DPCs in excess of 1000 µS, there are only two ways to attempt to resolve the problem.
That includes doing a BIOS upgrade and/or upgrading your PC’s hardware drivers, including the video, motherboard chipset and any other hardware you have connected to the PC. The data from LatencyMon can provide some insight into which driver is causing the problems. Be forewarned that not all DPC problems can be easily resolved, as the updated drivers may not correct the DPC problems.