是否有任何现代 Windows PC 中没有至少一个 DirectShow 捕获设备？
我正在考虑做一些可能看起来很奇怪的事情来获得一个可靠的时钟。我必须将缓冲区推送到 WiFi 连接的音频输出设备，该设备本身不进行缓冲或音频时间戳仲裁。如果我不定期发送缓冲区以与硬件采样器设备的时序合理匹配，则播放会损坏并开始卡顿。
在考虑下面描述的“黑客”之前，我首先研究了进行高分辨率计时的常见嫌疑人。 QueryPerformanceCounter 看起来不错，直到我读到硬件抽象层中存在缺陷的硬件实现以及可变 CPU 速度步进的复杂性破坏了 QPC 计算。此外，Windows 多媒体计时器仅精确到 1 毫秒，这使得其在 44.1 kHz 等高采样率下的使用值得怀疑。这就是为什么我正在考虑以下问题：
CPU 时钟频率，因此 QueryPerformanceCounter 错误？
据我所知，目前生产的每台 Windows PC 都至少有对麦克风的硬件支持。我正在考虑做的是“搭载”现有捕获设备的时钟。我有一个 DirectShow 推送源过滤器，它是发送到 WiFi 音频输出设备的音频的真正来源。我将强制捕获过滤器的采样率与推送源过滤器相匹配。然后，我将使用信号量锁定推送源过滤器的 FillBuffer() 调用，直到捕获过滤器的 FillBuffer() 调用生成缓冲区，从而控制捕获过滤器的缓冲区计时。
我可以指望用户的 PC 至少有一个捕获设备吗？此外，我们欢迎任何有关总体战略的评论。
I am considering doing something that might seem strange to get a reliable time clock. I have to push buffers to a WiFi connected audio output device that does not do buffering or audio timestamp arbitration on its own. If I don't send the buffers at regular periodic intervals that would match reasonably the timing of a hardware sampler device, the playback becomes corrupted and starts to stutter.
I looked at the usual suspects for doing high resolution timing first before considering the "hack" I describe below. QueryPerformanceCounter looked good until I read about buggy hardware implementations in the Harddware Abstraction Layer and the complexities of variable CPU speed stepping ruining the QPC calculations. Also, the Windows multimedia timer is only accurate to 1 millisecond making its use at high sampling rates like 44.1 kHz dubious. That's why I am considering the following:
CPU clock frequency and thus QueryPerformanceCounter wrong?
As far as I know every Windows PC currently made has at least hardware support for a microphone. What I am considering doing is "piggybacking" on an existing capture device's clock. I have a DirectShow push source filter that is the true source of the audio to be sent to the WiFi audio output device. I will force the Capture Filter's sample rate to match the push source filter. Then, I will use a semaphore to lock the push source filter's FillBuffer() call until the Capture Filter's FillBuffer() call produces a buffer, thereby riding the Capture Filter's buffer timing.
Can I count on a user's PC having at least one Capture Device? Also, any comments about the overall strategy are appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
系统参考时钟 是一个可靠的时钟，精度约为毫秒，您可以在任何带有或不带有 DirectShow 捕获设备的 PC 上使用它。
人们可能要处理的问题是，tghis 时钟与音频捕获或播放设备的时钟不完全匹配，并且长期的声音流由于时钟不匹配而累积误差。 DirectShow 速率匹配就是为了解决这个问题。
另一方面，如果您需要一个具有更高准确度/精确度的好时钟，您可以使用由
QueryPerformanceCounter支持的时钟，但定期重新同步以保持长期准确性，请参阅类 DateTimePrecise。另外：
System Reference Clock is a relaible clock with around millisecond accuracy, and you have it in any PC with or without DirectShow capture devices.
The problem one might be dealing with is that tghis clock does not exactly match the clock of audio capture or playback device, and a long term sound streamed accumulates an error due to mismatch of the clocks. DirectShow rate matching is something to address the problem.
On the other hand if you need a good clock with higher accuracy/precision, you can use the one backed by
QueryPerformanceCounterbut being resync'ed on a regular basis to keep long term accuracy, see class DateTimePrecise.Also: