设备驱动程序无法在其中断例程中立即处理数据。它必须安排延迟过程调用 (DPC)，这基本上是一个回调例程，操作系统将尽快调用它。...系统中每个 CPU 都有一个 DPC 队列。 ... 如果任何 DPC 运行时间过长，则其他 DPC 也会延迟该时间。... 不幸的是，许多现有的设备驱动程序不遵循此建议。此类驱动程序在其 DPC 例程中花费了过多的时间，导致其他驱动程序的 DPC 出现异常大的延迟。对于实时处理数据流的设备驱动程序，在硬件发出下一个中断之前执行从其中断例程调度的 DPC 至关重要。如果 DPC 延迟并在下一个中断发生后运行，通常会发生硬件缓冲区溢出，数据流会中断。发生丢失。
DPC 被排入全局 DPC 队列，并且可以在任何处理器上运行。因此，如果您在一个核心上确实有一个长时间（运行）的 DPC，则另一个核心可以自由地处理另一个。因此，任何时间信息实际上都取决于您拥有的处理器数量以及当前同时执行的任务数量。因此，在多核处理器上，这些数字可能会有很大差异。
一般来说，我读到的是，对于音频来说，快速的双核比较慢的四核更好，因为大多数音频应用程序并未针对使用多核进行优化。
但在现代计算机中，DPC 问题似乎是音频制作的瓶颈。这是否意味着四核处理器比双核处理器更好？其他空闲核心理论上可以处理音频 DPC，而其中一个核心被粗鲁的 Wi-Fi DPC 例程锁定。队列是否在核心之间共享，DPC 是否可以被转移到空闲的核心？或者每个核心都有一个队列，允许劫持核心？虚拟核心怎么样？
答案1
延迟过程调用 (DPC) 中的延迟是由于驱动程序花费很长时间来完成其工作造成的。
添加更多 CPU 不会改善编写不佳的驱动程序执行处理所需的时间。
答案2
重新讨论旧话题（抱歉）。在我看来，并行计算和多核的承诺尚未完全实现用于音频工作。在（好的？）过去的日子里（如上所述），当双处理器成为可能时，承诺是一个处理器可以处理图形，而另一个处理器专注于音频。而且你通过调整和更高的音频缓冲区解决了 DPC 问题。这在某些 DAW（例如 Logic）中起到了提高效率的作用。但现在我的新笔记本电脑有八个核心（据说像 8 个独立的处理器 - 或 16 个开启超线程的处理器），DPC 延迟问题和以往一样严重。即使关闭 wifi 和大多数其他功能，全功率和较大的缓冲区（512 个样本），DJing 软件仍然会偶尔出现故障（它本身不会对 CPU 造成太大负担）。DPC 延迟为 4,000-10,000！我非常害怕它在性能上发生，因此一直小心地只在非关键情况下使用这台机器。另一方面，我的台式双 Xeon 音频工作站的 DPC 始终保持在 500 左右，非常完美。也许诀窍在于双实际 CPU，而不是核心。