什么是Windows“事件队列瓶颈”以及我应采取哪些措施来防止这种情况发生？

Question

我有一个多线程DirectShow应用程序，它使用套接字与Skype之间传输音频。它是使用DSPACK组件套件在Delphi 6中编写的。用于与Skype交换音频数据的套接字组件来自ICS套接字库。 ICS组件使用非阻塞套接字，这些套接字使用Windows消息循环来完成工作，而不是像Indy或Synapse组件那样使用阻塞套接字。我有每个socket都有自己的实时关键工作线程。在我发表关于ICS套接字和后台线程的Stack Overflow帖子中，我发表了关于切换到Indy以避免Windows“事件队列瓶颈”的评论：

How can I push a TWSocket's OnDataAvailable() event to a background thread in my Delphi 6 application?

有人可以告诉我这是什么以及我需要采取哪些措施来预防/避免这个问题？

注意，我有两个ICS插槽，用于处理Skype的音频双向（双工）连接。一个用于向Skype发送音频，另一个用于从Skype接收音频。我将音频缓冲区设置为等于100毫秒音频数据的大小。因此，数据每秒发送10次到Skype，相反，每秒从Skype收到10次。每个套接字都有自己的线程设置为实时工作的关键优先级。

我的问题的原因是这个。该应用程序现在运作良好。在我修复了一些错误之前，我会看到音频发送和接收流的延迟逐渐增加。现在我可以在音频流中没有任何延迟的情况下运行几分钟，但在那之后，开始的时间变化很大，一些小的延迟开始蔓延。我注意到以下症状：

1. 如果我有大量的OutputDebugString（）消息，则延迟仅在20-30秒后发生，并在此之后呈指数级变差（快速降级）。删除OutputDebugString（）消息可以缓解此问题：

How can I keep a large amount of OutputDebugString() calls from degrading my application in the Delphi 6 IDE?

1. 从我的应用程序切换回Delphi IDE会导致延迟注入音频流。显然，关于开关的一些东西，我监控的工作和监控关键部分保持多长时间的代码会弹出警告信息，其中一个关键部分被保留了很长时间（超过100毫秒，这显然是一个问题）。

注意：我用来向Skype发送命令消息字符串并从Skype接收状态和结果消息字符串的两个线程也是基于GetMessage（）的，因为它与Skype连接与使用WM_COPYDATA消息的Windows SendMessage（）API调用同步完成。

考虑到音频传输的频率，问题是由于Windows“事件队列瓶颈”造成的，或者更可能是我的线程同步方案效率低下？