如何创建一个线程来模拟生成音频数据时捕获过滤器的精确计时？
我有一个 DirectShow 推送源过滤器，它从没有时间戳的自定义音频流中累积数据。它缓冲它们，然后将它们发送到外部音频输出设备，该设备通过设备提供的 HTTP 服务器接受音频缓冲区（您通过 HTTP 向其提交音频缓冲区）。不幸的是，音频输出设备对时间敏感。一次发送太多数据或（自然）太少数据会使其混乱并导致播放问题，例如“卡顿”。
我需要以精确的时间间隔通过 HTTP 连接发送缓冲区，就像使用基于硬件的采样和时钟的捕获设备在发布捕获的数据时的精度一样。我假设我必须创建一个实时关键线程并使用它。这是我的问题：
我应该如何安排时间？我应该使用哪些 Windows API 调用和数据结构来正确执行此操作？使用 Windows 性能计数器功能的东西？
当我还没有准备好在推送源过滤器的 FillBuffer() 方法中发布任何数据时，如何阻止？互斥体？信号量？
如何避免漂移？例如，如果我需要生成 50 毫秒的缓冲区，并且正在模拟 8000 的采样率，那么如何确保我不会以随时间累积的方式低于或超过计算的发布时间，从而可能导致音频中出现间隙？
I have a DirectShow push source filter that accumulates data from custom audio streams that are not timestamped. It buffers them, and then sends them to an external audio output device that accepts audio buffers via an HTTP server the device provides (you submit it audio buffers via HTTP). The audio output device is unfortunately timing sensitive. Sending it too much data at once or (naturally) too little data at a time confuses it and causes playback problems such as "stuttering".
I need to send it buffers over an HTTP connection at a precisely timed interval, just like the precision a capture device that uses hardware based sampling and clocking does when it publishes captured data. I assume I have to create a real-time critical thread and use it. Here are my questions:
How I should do the timing? What Windows API calls and data structures do I use to do this correctly? Something using the Windows performance counter features?
How do I block when I am not ready to publish any data in my push source filter's FillBuffer() method? Mutex? Semaphore?
How do I avoid drift? For example, if I need to generate a 50 millisecond buffer and I am emulating a sample rate of 8000, how do I make sure that I am not undershooting or overshooting the calculated publication time in a way that would accumulate over time, possibly leading to gaps in the audio?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
关于时间和漂移；您可以执行以下操作：
StreamingPos中。StreamingPos就会增加 50 毫秒。StreamingPos之前不要发送任何进一步的数据。这样您就可以将数据速率同步到本地系统时间。这不需要与播放器设备的时钟完全匹配。但这应该不是问题。解决这个问题的唯一方法是让两个设备与相同的时间源同步。
regarding the timing and the drifting; you could do the following:
StreamingPos.StreamingPosby 50ms.StreamingPos.This way you will sync the datarate to your local systemtime. This does not need to match exactly the clock of the player device. But that should not be a problem. The only way to solve that is having both devices synchronised with the same timesource.