2

我正在考虑做一些看起来很奇怪的事情来获得一个可靠的时钟。我必须将缓冲区推送到连接 WiFi 的音频输出设备，该设备本身不进行缓冲或音频时间戳仲裁。如果我不以与硬件采样器设备的时序合理匹配的定期间隔发送缓冲区，则播放会损坏并开始卡顿。

在考虑我在下面描述的“黑客”之前，我首先查看了通常的嫌疑人进行高分辨率计时。QueryPerformanceCounter 看起来不错，直到我读到硬件抽象层中的错误硬件实现以及可变 CPU 速度步进破坏 QPC 计算的复杂性。此外，Windows 多媒体计时器只能精确到 1 毫秒，这使得它在 44.1 kHz 等高采样率下的使用令人怀疑。这就是为什么我正在考虑以下内容：

CPU时钟频率和QueryPerformanceCounter错了吗？

据我所知，目前生产的每台 Windows PC 都至少有麦克风的硬件支持。我正在考虑做的是在现有捕获设备的时钟上“捎带​​”。我有一个 DirectShow 推送源过滤器，它是要发送到 WiFi 音频输出设备的音频的真正来源。我将强制捕获过滤器的采样率与推送源过滤器匹配。然后，我将使用信号量来锁定推送源过滤器的 FillBuffer() 调用，直到 Capture Filter 的 FillBuffer() 调用产生一个缓冲区，从而利用Capture Filter 的缓冲区计时。

我可以指望用户的 PC 上至少有一个 Capture Device 吗？此外，对整体战略的任何评论表示赞赏。

4

1 回答 1

3

系统参考时钟是一个可靠的时钟，精度约为毫秒，您可以在任何带有或不带有 DirectShow 捕获设备的 PC 中使用它。

可能要处理的问题是 tghis 时钟与音频捕获或播放设备的时钟不完全匹配，并且由于时钟不匹配而长期流式传输的声音会累积错误。DirectShow速率匹配可以解决这个问题。

另一方面，如果您需要一个具有更高准确度/精度的良好时钟，您可以使用支持QueryPerformanceCounter但定期重新同步的时钟以保持长期准确性，请参阅类 DateTimePrecise。

还：

于 2011-11-20T07:06:49.117 回答