预加载音频缓冲区-什么是合理和可靠的？

Question

我正在转换一个音频信号处理应用程序从Win XP到Win 7(至少)。你可以想象它是一个声纳应用程序-一个信号被生成和发送出去，一个相关的/修改的信号被读取回。该应用程序希望只使用音频硬件，并且不能承受故障--我们不想读像"Windows beep导致导弹发射“这样的头条新闻。

查看Windows音频示例，与我的案例最相关的是RenderExclusiveEventDriven示例。在音频引擎之外，它准备播放10秒的音频，这将通过IAudioRenderClient对象的GetBuffer()和ReleaseBuffer()以10‘s块的形式提供给呈现引擎。它首先使用这些函数预加载单个10 on的音频块，然后依赖于常规的10 on事件加载后续块。

希望这意味着将始终有10-20毫秒的音频数据缓冲。我们应该期望它在合理的现代硬件(不到18个月的历史)上有多可靠(即无故障)？

以前，人们可以通过waveXXX() API预装至少半秒钟的音频，这样如果Windows在其他地方忙碌，那么音频连续性就不太可能受到影响。500毫秒比10-20毫秒安全得多.但是，如果您想要事件驱动模式和独占模式，那么IAudioRenderClient文档并不能确切地说明它是否能够预加载超过一个IAudioRenderClient缓冲区的值。

有人能确认是否还有可能进行更广泛的预加载吗？它是推荐的，气馁的，还是两者都没有？

Answer 1

如果您担心发射导弹，我认为您不应该使用Windows或任何其他非实时操作系统。

也就是说，我们正在开发另一个应用程序，它消耗更高的数据带宽(400 MB/s连续工作几个小时或更长时间)。我们已经看到了操作系统在5秒内无法响应的故障，因此我们在数据采集硬件上有大量的缓冲区。

Answer 2

就像计算中的其他东西一样，你走得越远：

• 增加吞吐量
• 增加延迟

我想说的是，512个示例缓冲区是用于不需要延迟的应用程序的最小值。我见过多达4k的缓冲区。内存使用明智，这仍然是几乎没有现代设备-只有8千字节的内存，每通道16位音频。你有更好的回放稳定性和较低的CPU周期浪费。对于音频应用程序，这意味着在音频开始跳过之前，您可以使用更多的DSP处理更多的曲目。

另一方面，我只看到了一些专业的音频接口，它可以处理32个示例缓冲区。大多数可以达到128个样本，自然地，你仍然被限制在较低的通道和效果计数，即使使用专业的硬件，你增加缓冲随着你的项目变得更大，降低它回和禁用轨道或效果，当你需要“实时”捕捉一个性能。就最低可能的延迟而言，实际上，与不允许在Windows上执行此类操作的Windows上相比，同一个框能够在Linux和自定义实时内核中实现更低的延迟。请记住，从理论上讲，64个示例缓冲区听起来可能像是8毫秒的延迟，但实际上它更像是double --因为您有输入和输出延迟加上处理延迟。

对于一个没有延迟问题的音乐播放器来说，你完全可以使用更大的缓冲区。对于游戏之类的东西，为了在视觉上和声音之间保持一定程度的同步，你需要保持更低的速度--你根本不能让你的声音滞后半秒钟，因为音乐表演和已经录制好的素材一起拍摄，你需要低延迟。您不应该超过您的用例要求，因为一个小的缓冲区将不必要地增加CPU的使用和获得音频中断的几率。对于一个音频播放器来说，4k缓冲是很好的，如果你在点击播放的那一刻和听到歌曲启动之间有半秒钟的等待时间的话，那就很好了。

我在我的DAW项目中做了一种“混合”解决方案--因为我想使用GPGPU来实现它相对于CPU的巨大性能，我在内部使用了两种处理路径--在CPU上处理的实时音频的64个示例缓冲区，以及GPU处理的数据的另一个更大的缓冲区大小。当然，它们都是通过"CPU缓冲区“来实现完美同步的，但是GPU路径是”预先处理“的，从而允许对已经记录的数据进行更高的吞吐量，并且保持CPU使用率更低，这样实时音频就更可靠了。老实说，我感到惊讶的是，专业的DAW软件还没有走上这条路，但并不是太多，因为我知道这个行业的大鱼在硬件上赚了多少钱，这些硬件比现代中档GPU强大得多。自从Cuda和OpenCL问世以来，他们就一直声称“GPU的延迟太大了”，但是对于已经被记录的数据来说，预缓冲和预处理实际上并不是一个问题，并且极大地增加了DAW能够处理的项目的规模。

Answer 3

简单地说，是的，您可以预加载更多的数据。

此示例使用对GetDevicePeriod的调用来返回设备的最小服务间隔(以纳米秒为单位)，然后将该值传递给Initialize。如果您愿意，可以传递更大的值。

增加周期的缺点是增加了延迟。如果你只是在播放一个波形回放，而不是计划在飞行中作出改变，那么这不是一个问题。但是如果你有一个正弦发生器，那么延迟时间的增加意味着你需要更长的时间才能听到频率或振幅的变化。

你是否有辍学取决于很多事情。是否适当地设置线程优先级？缓冲器有多小？您准备样品时使用了多少CPU？然而，一般来说，现代CPU可以处理相当低的延迟.作为比较，ASIO音频设备在96 For时运行得非常好，有一个2048个示例缓冲区(20毫秒)，有多个通道--没有问题。ASIO使用类似的双缓冲方案。