OpenCL GPU 音频

Question

关于这个主题的内容不多，也许是因为它一开始就不是一个好主意。

我想创建一个在 GPU 上运行的实时音频合成/处理引擎。这样做的原因是因为我还将使用在 GPU 上运行的物理库，音频输出将由物理状态决定。 GPU是真的只承载音频输出，不能生成吗？如果我要在 CPU 上读回数据并将其输出到声卡，这是否意味着延迟会大幅增加？就合成和播放之间的时间而言，我正在寻找 10 到 20 毫秒之间的延迟。

GPU 是否会以任何有价值的速度加速合成？我将同时运行大量合成器，我想每个合成器都可以占用它们自己的并行过程。 AMD 正在推出 GPU 音频，所以这一定是有原因的。

Answer 1

您可以查看NESS project，它是关于物理建模综合的。他们使用 GPU 进行音频渲染，因为该过程涉及为任何给定的声音模拟声学 3D 空间，并计算在虚拟 3D 空间中该声音会发生什么（显然 GPU 擅长处理此类数据）。请注意，这不是实时合成，因为它对处理要求很高。

Answer 2

http://arxiv.org/ftp/arxiv/papers/1211/1211.2038.pdf 使用 OpenMP 可能会更好，因为它的初始化时间较短。

Answer 3

对于它的价值，我不确定这个想法是否缺乏价值。如果 DarkZero 对传输时间的观察是正确的，那么即使从许多不同的输入通道获取音频到 GPU 上进行处理，听起来也不会有太多开销，虽然可能存在不太适合并行化的音频操作，许多都非常可并行化。

很明显，例如，计算来自正弦源的 128 个输出样本的正弦值可以完全并行完成。在这种大小的块中工作只允许大约 3 毫秒的延迟，这在大多数数字音频应用中是可以接受的。同样，许多其他基本振荡器可以有效地并行化。这种振荡器的幅度调制将是微不足道的。高效的频率调制会更具挑战性，但我想这仍然是可能的。

除了振荡器之外，FIR 滤波器很容易并行化，谷歌搜索发现了一些看起来很有前途的研究论文（我没有费心去阅读），这些论文表明 IIR 滤波器实现有合理的并行方法.这两种类型的过滤器是音频处理的基础，许多有用的音频操作都可以理解为此类过滤器。

波形整形是数字音频中另一个令人尴尬的并行任务。

即使您无法使用任意软件合成器并将其有效地映射到 GPU，也很容易想象专门构建的软件合成器可以利用 GPU 的优势并避免其弱点。完全依赖我提到的组件的合成器仍然可以产生美妙的声音。

虽然 marko 正确地指出现有 SIMD 指令可以在 CPU 上进行一些并行化，但与良好的 GPU 相比，它们可以同时操作的输入数量相形见绌。

总之，我希望你在这方面努力，让我们知道你看到了什么样的结果！

Answer 4

如果利用得当，现代 CPU 上带有矢量处理单元的 DSP 操作（x86/x64 上的 SSE 或 ARM 上的 NEON）已经非常便宜了。对于过滤器、卷积、FFT 等来说尤其如此——它们基本上是基于流的操作。在某些类型的操作中，GPU 也可能表现出色。

事实证明，软合成器中有相当多的操作不是流式的，此外，趋势是一次处理越来越小的音频块以实现低延迟。这些与 GPU 的功能非常不匹配。

使用 GPU 所付出的努力 - 尤其是输入和输出数据 - 可能远远超过您获得的任何好处。此外，廉价的个人电脑——以及平板电脑和移动设备——的功能对于许多数字音频应用来说已经绰绰有余了。AMD似乎有一个寻找问题的解决方案。可以肯定的是，现有的音乐和数字音频软件行业不会开始生产只针对有限的硬件子集的软件。

Answer 5

一些 MB 与 GPU 之间的典型传输时间需要 50us。

延迟不是您的问题，但是在 GPU 中并行化音频合成器可能相当困难。如果您没有正确执行此操作，则可能需要更多时间来处理而不是复制数据。

如果您要同时运行多个合成器，我建议您在一个工作组中执行每个合成器，并将合成过程与可用的工作项并行化。将每个合成器放在一个工作项中是不值得的，因为您不太可能有一千个。