DPC latency checker says
A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC) which basically is a callback routine that will be called by the operating system as soon as possible. ... There is one DPC queue per CPU available in the system. ... If any DPC runs for an excessive amount of time then other DPCs will be delayed by that amount of time. ... Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver's DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs.
Stack Overflow answer says:
A DPC is queued into the global DPC queue, and can be run on any processor. So if you really have a long (-running) DPC on one core, the other core is free to process another. So any timing information is really dependent on the count of processors you have and how many things get currently executed concurrently. So on multicore processors these numbers might vary widely.
Generally what I've read is that a fast dual core is better than a slower quad core for audio, since most audio apps aren't optimized to use more than one core.
But in modern computers it sounds like DPC issues are bottleneck for audio production. Does this mean a quad core processor would be better than a dual core? Other free cores could theoretically handle the audio DPCs while one is locked up by a rude Wi-Fi DPC routine. Is the queue shared between cores, and DPCs can be shuffled around to whichever one is free? Or is there one queue per core, allowing for a core to be hijacked? What about virtual cores?