directshow - 是否有任何现代 Windows PC 中至少没有一个 DirectShow 捕获设备？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




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

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

CPU clock frequency and thus QueryPerformanceCounter wrong?

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

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

Answer 1

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

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

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

还:

C# DateTime.Now precision

Windows system time with millisecond precision

Microsecond resolution timestamps on Windows

How to realise long-term high-resolution timing on windows using C++?