OpenCL GPU音频

Question

关于这个问题并不多，也许是因为它首先不是一个好主意。

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

GPU会以任何有价值的数量加速合成吗？我将同时运行大量的合成器，我想每个合成器都可以采用自己的并行过程。 AMD正在推出GPU音频，因此必须有一些东西。

Answer 1

对于它的价值，我不确定这个想法缺乏价值。如果DarkZero关于传输时间的观察是正确的，那么听起来就像将音频传输到GPU进行处理一样，即使是从许多不同的输入通道也是如此，虽然可能有音频操作不太适合并行化，很多都非常可并行化。

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

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

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

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

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

简而言之，我希望您能够解决这个问题，让我们知道您看到了什么样的结果！

Answer 2

具有矢量处理单元的现代CPU上的DSP操作（在x86 / x64上的SSE或ARM上的NEON）如果被正确利用已经相当便宜。滤波器，卷积，FFT等尤其如此 - 这些基本上是基于流的操作。有一种类型的操作，GPU也可能出类拔萃。

事实证明，软合成器在其中有很多不像流一样的操作，而且，趋势是一次处理越来越小的音频块以达到低延迟。这些都非常适合GPU的功能。

使用GPU所需的工作 - 尤其是数据输入和输出 - 可能远远超过您获得的任何好处。此外，便宜的个人计算机 - 以及平板电脑和移动设备 - 的功能对于许多数字音频应用来说已经足够了AMD似乎有一个寻找问题的解决方案。当然，现有的音乐和数字音频软件行业不会开始生产仅针对有限的硬件子集的软件。

Answer 3

某些MB与GPU之间的典型传输时间为50us。

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

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

Answer 4

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

Answer 5

您可以查看NESS项目，该项目与物理建模综合有关。他们使用GPU进行音频渲染，因为它的过程包括为任何给定的声音模拟声学3D空间，并计算虚拟3D空间内的声音会发生什么（显然GPU很好地处理这类数据）。请注意，这不是实时合成，因为它对处理要求很高。 http://www.ness-music.eu/overview/large-scale-synthesis-on-gpus