Windows 7 在Windows Vista及更新版本中播放音频或视频时，是什么导致网络性能不佳？
所讨论的软件是一个原生C++/MFC应用程序，它通过UDP接收大量数据，然后处理这些数据以进行显示、声音输出和写入磁盘等。当应用程序的CHM帮助文档从其帮助菜单启动时，我首先遇到了这个问题，然后在从硬件收集数据时，我单击了帮助文档。为了复制这一点，在应用程序运行时，使用自动热键脚本在帮助文档中快速单击。系统一发出声音，我就开始出错 如果我完全禁用了声卡，尽管声音输出明显被禁用，但一切处理都很好，没有错误。然而，如果我有声音播放（在这个应用程序中，一个不同的应用程序，甚至只是一个消息框中的嘟嘟声），我会收到数千个丢弃的数据包（我们知道这一点，因为每个数据包都有时间戳）。作为第二个测试，我根本没有使用我的应用程序，只是使用Wireshark监视来自硬件的传入数据包。果不其然，每当有声音在Windows中播放时，我们都会丢弃数据包。事实上，声音甚至不需要主动播放就能导致错误。如果我只是创建了一个缓冲区（使用DirectSound8）而从未开始播放，我仍然会遇到这些错误 这种情况发生在具有多种网卡（光纤和RJ45）和声卡（集成卡和独立卡）组合的多台PC上。我还为每个NIC和声卡尝试了不同的驱动程序版本。所有测试都是在Windows7 32位上进行的。由于我的应用程序将DirectSound用于音频，我尝试了不同的协作级别（正常操作为DSSCL_优先级），但没有成功Windows 7 在Windows Vista及更新版本中播放音频或视频时，是什么导致网络性能不佳？,windows-7,windows-vista,udp,directsound,Windows 7,Windows Vista,Udp,Directsound,所讨论的软件是一个原生C++/MFC应用程序，它通过UDP接收大量数据，然后处理这些数据以进行显示、声音输出和写入磁盘等。当应用程序的CHM帮助文档从其帮助菜单启动时，我首先遇到了这个问题，然后在从硬件收集数据时，我单击了帮助文档。为了复制这一点，在应用程序运行时，使用自动热键脚本在帮助文档中快速单击。系统一发出声音，我就开始出错 如果我完全禁用了声卡，尽管声音输出明显被禁用，但一切处理都很好，没有错误。然而，如果我有声音播放（在这个应用程序中，一个不同的应用程序，甚至只是一个消息框中的嘟嘟声）
在这一点上，我非常确信这与我的应用程序无关，并且在我开始与硬件供应商和/或Microsoft打交道之前，我想知道是否有人知道是什么导致了这个问题。事实证明，这种行为是出于设计。Windows Vista和后来实现了一种称为的功能，旨在使所有多媒体播放尽可能流畅。由于多媒体播放依赖于硬件中断来确保平滑播放，因此任何竞争性中断都会导致问题。网络流量是主要的硬件中断源之一。正因为如此，微软决定在MMCSS下运行程序时限制网络流量 我想这是一个倒退，但我错过了。有一篇马克·鲁西诺维奇的文章（谢谢）。我的整个问题似乎归结为： 因为标准以太网帧 大小约为1500字节，限制为 每秒10000个数据包等于 最大吞吐量约为15MB/s。 100Mb网络最多可以处理 12MB/s，因此如果您的系统处于 100Mb网络，您通常不会看到 任何减速。但是，如果您有 1Gb网络基础设施和两者 发送系统和您的Vista 接收系统有1Gb网络 适配器，您将看到吞吐量下降 大约15%。此外，还有一个 NDIS节流中的不幸错误 如果需要，则会放大节流的代码 有多个NIC。如果你有 具有无线和有线功能的系统 例如，NDIS将使用适配器 每天最多处理8000个数据包 第二，它有三个适配器 将最多处理6000个数据包 每秒。每秒6000包 等于9MB/s，这是一个可见的限制 即使在100Mb网络上 我还没有验证Windows7或Vista SP1中是否仍然存在多适配器错误，但如果遇到问题，可以查找它 从Russinovich的帖子中，我发现Vista SP1引入了一些注册表设置，可以调整MMCSS对Windows的影响。特别是 我的问题的解决方案是通过将
HKEY\U LOCAL\U MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\NetworkThrottlingIndex0xFFFFFFFF70到目前为止，我还没有看到这一变化对其他多媒体应用程序（也没有看到我自己的应用程序的视频捕获和音频输出部分）产生任何不利影响。如果情况发生变化，我将在这里报告。众所周知，微软在Windows Vista内核中构建了一些奇怪的反功能，可以预防性地降低I/O性能，以确保多媒体应用程序（Windows media player、directX）获得100%的响应能力。我不知道这是否也意味着UDP的数据包丢失。请阅读此方法的蹩脚理由：
其中一条评论对此做了很好的总结：“在我看来，微软似乎试图‘修复’一些没有损坏的东西。”众所周知，微软在Windows Vista内核中构建了一些奇怪的反功能，可以预防性地降低I/O性能，以确保多媒体应用程序（Windows media player、directX）获得100%的响应能力。我不知道这是否也意味着UDP的数据包丢失。读一下这种方法的蹩脚理由：其中一条评论很好地概括了这一点：“在我看来，微软试图‘修复’一些没有被破坏的东西。”你知道这就是UDP的问题，对吗？这是一种不可靠的传递方法，因此错误检查必须包含在UDP之外的协议中。或者，只需使用TCP此外，“你有ypnos提供的信息-我没有暴露/可见性）@KevinDTimm-我知道UDP根据定义是不可靠的。因为它在没有声音的情况下无限期地无误运行