关于这个主题的内容不多，也许是因为它首先不是一个好主意。
我想创建一个在 GPU 上运行的实时音频合成/处理引擎。这样做的原因是因为我还将使用在 GPU 上运行的物理库，并且音频输出将由物理状态决定。 GPU是不是只承载音频输出而不能产生它？如果我要在 CPU 上读回数据并将其输出到声卡，这是否意味着延迟会大大增加？在合成和播放之间的时间方面，我正在寻找 10 到 20 毫秒之间的延迟。
GPU 会以任何有值(value)的方式加速合成吗？我将同时运行大量合成器，我认为每个合成器都可以占用自己的并行过程。 AMD 即将推出 GPU 音频，因此必须有所作为。
最佳答案
就其值(value)而言，我不确定这个想法是否有值(value)。如果 DarkZero 对传输时间的观察是正确的，那么即使来自许多不同的输入 channel ，将音频传送到 GPU 进行处理听起来也不会有太多开销，而且可能存在不太适合并行化的音频操作，许多是非常非常可并行化的。
例如，很明显，可以完全并行地计算来自正弦源的 128 个输出样本的正弦值。在这种大小的块中工作只允许大约 3 毫秒的延迟，这在大多数数字音频应用程序中是可以接受的。同样，许多其他基本振荡器可以有效地并行化。这种振荡器的幅度调制将是微不足道的。有效的频率调制会更具挑战性，但我猜它仍然是可能的。
除了振荡器之外，FIR 滤波器很容易并行化，谷歌搜索发现了一些很有前景的研究论文(我没有费心去阅读)，这些论文表明 IIR 滤波器实现有合理的并行方法。这两种类型的过滤器是音频处理的基础，许多有用的音频操作都可以理解为这样的过滤器。
波形整形是数字音频中另一个令人尴尬的并行任务。
即使您无法使用任意软件合成器并将其有效地映射到 GPU，也很容易想象专门构建的软件合成器可以利用 GPU 的优势并避免其弱点。完全依赖我提到的组件的合成器仍然可以产生一系列美妙的声音。
虽然 Marko 指出现有的 SIMD 指令可以在 CPU 上进行一些并行化是正确的，但与好的 GPU 相比，它们可以同时操作的输入数量相形见绌。
简而言之，我希望您为此努力，并让我们知道您看到了什么样的结果!
关于audio - OpenCL GPU 音频，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20080892/