为什么向我的 DirectShow Filter Graph 添加渲染器可以平滑图形中的音频输入？
我的 Delphi 6 应用程序中有一个使用 DSPACK 组件库构建的 DirectShow 过滤图。该图的结构如下：
- 自定义推送源音频过滤器
- Sample Grabber
- Tee Filter（但仅当我同时打开 WAV File Writer 和 Renderer 时）
- Renderer（首选 PC 输出设备）
- WAV File Writer
Tee Filter 添加到仅当我同时打开渲染器和 WAV 文件写入器过滤器时才显示图表。否则，我仅将已打开的过滤器直接连接到样本采集器。
音频通过连接 WiFi 的 RTSP 音频服务器进行传输，该服务器实时传输音频。如果我不打开 Wav 文件编写器，则从我的耳机输出的音频会出现与无缓冲音频流相关的典型抽吸声和偶尔的咔嗒声。奇怪的是，一旦我打开 WAV File Writer 过滤器，音频就变得像玻璃一样光滑。
我有 WAV 文件写入器的源代码，它基本上处理在需要时输出正确的 WAV 文件头和根据需要写入音频缓冲区的任务，仅此而已。所以我觉得很奇怪，打开它可以平滑传入的音频流，特别是因为它不是渲染器（过滤器）的上游，而是一个挂在渲染器旁边的 Tee 过滤器末端的对等过滤器。
谁能告诉我，当我打开“文件写入器”过滤器时，可能会发生什么情况以使音频传输顺利？ T 型过滤器是否具有任何固有的缓冲功能？我想复制相同的机制，这样当文件写入器未打开时我可以拥有流畅的音频。我试图避免添加自己的缓冲，因为我不想给实时音频流添加不必要的延迟。
I have a DirectShow filter graph in my Delphi 6 application built with the DSPACK component library. The structure of the graph is as follows:
- Custom push source audio filter
- Sample Grabber
- Tee Filter (but only when I turn on both the WAV File Writer and Renderer)
- Renderer (preferred PC output device)
- WAV File Writer
The Tee Filter is added to the graph only if I have both the Renderer and the WAV File Writer filters turned on. Otherwise I connect only the filter that is turned on directly to the Sample Grabber.
The audio is being delivered over a WiFi connected RTSP audio server that is streaming audio in real-time. If I don't turn on the Wav File Writer, the audio coming out my headphones has the typical pumping and occasional clicking sounds associated with an unbuffered audio stream. Strangely enough, as soon as I turn on the WAV File Writer filter the audio becomes smooth as glass.
I have the source code for the WAV File Writer and it basically handles the tasks of outputting the proper WAV file header when needed and writing the audio buffers as necessary, not much more than that. So I find it strange that turning it on smooths the incoming audio stream, especially since it is not upstream of the Renderer (filter) but instead is a peer filter hanging off the end of the Tee Filter alongside the Renderer.
Can anyone tell me what might be happening to make the audio delivery smooth out when when I turn on the File Writer filter? Does the Tee Filter do any inherent buffering? I want to duplicate the same mechanism so I can have smooth audio when the File Writer is not turned on. I'm trying to avoid adding my own buffering because I don't want to add any more delay to the real time audio stream than I have to.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您有实时源并且可以同时收听它和传送的音频，您也许能够判断添加文件编写器是否会引入延迟，这可能是造成差异的原因。或者
DecideBufferSize中协商的缓冲区的大小或数量可能发生变化。我建议在推送过滤器中引入显式缓冲，例如向媒体样本时间戳添加偏移量。 T 形过滤器中的固有缓冲可能不可靠。交货时间的变化是不可避免的。
如果您需要以最小缓冲或无缓冲运行，更复杂的方法可能是在保留音高的同时拉伸/压缩音频。
If you have a live source and you can listen to it and the delivered audio at the same time, you may be able to tell whether adding File Writer introduces a delay, that may be accountable for the difference. Or there may be a change in size or the number of negotiated buffers in
DecideBufferSize.I would suggest introducing explicit buffering in your push filter, like adding an offset to media sample time-stamps. Inherent buffering in Tee filter may be not reliable. Variations in delivery time are inevitable.
A more sophisticated approach, if you need to run with minimal or no buffering, could be to stretch/compress the audio while preserving the pitch.