audio - 哪些音频 API 可以支持推测性评估和校正？

Question

推测性评估(又名推测性执行)是一种以偶尔返工(低效率)为代价实现低延迟代码的有效方法。推测评估是现代计算机体系结构的一种常见的低级技术，但它可以在更高级别的编程模型(参见时间扭曲协议(protocol)、时间逻辑、响应式(Reactive)编程模型)中得到支持。

一个似乎推测性评估特别有用的地方是音频的实时计算，例如用于实时编码或游戏。这个想法很简单:我们可以推测性地填充音频缓冲区以防止缓冲区欠载，但如果我们必须对任何最后即时更改使用react，则偶尔会纠正这些缓冲区。这种技术仍然可能出现故障。零散的更新可能会从前面砍掉一点。但是由于大多数推测的声音应该仍然大部分是正确的，因此与典型的欠载相比，这是一种不同的 - 并且可能更优雅的故障模式。

现在，我想知道哪些音频 API 或库最有效地支持这些对现有缓冲区的最后即时更新。我不是声音编程方面的专家，但我见过的大多数示例代码似乎都假定了对缓冲区的 promise 。如果我在加载缓冲区后 promise 使用缓冲区，那么别无选择，只能在延迟和欠载风险之间进行权衡。哪些音频 API 不需要 promise ？

Answer 1

一旦包含声音的缓冲区被传递到您的声卡，通常为时已晚以任何方式对其进行修改。我似乎记得微软试图引入一个音频驱动模型，允许你直接写入声卡的内存缓冲区(WaveRT)，但由于 USB 声卡不支持它，它并没有获得太多的牵引力。

所有音频 API 都会有一种方法，您可以提供要播放的缓冲区，或填充给定的缓冲区。完成此操作后，无法保证更改该位置的内存会产生任何影响(甚至可能导致崩溃)。使用 windows waveOut API，您可以将多个缓冲区排队，因此您可以在声卡开始播放之前更改一个。但是，它不是一个低延迟的 API，所以正在播放的 API 可能会在 50 毫秒左右。

大多数需要非常灵敏的声音的应用程序只是在低延迟下工作。从音频处理的角度来看，追溯修改已经写入的缓冲区的一部分通常非常困难，因为如果不淡入淡出，换出音频可能会导致爆音和咔嗒声，并且任何 DSP您传递的音频可能处于无法重现的状态。