GPU音频处理
首先，碰巧我是一个编程知识很少的吉他手（说实话，我对此更感兴趣，而不是我可以做任何事情）。所以前几天我正在研究神经网络的工作，这让我研究了使用视频卡进行数学计算。Guitar Rig 等程序总是有一些延迟。在我的理解中，使用这样的程序转换声音只是对声音进行的数学运算（是的，可能说得太简单和不准确，但我认为本质是正确的）。我想知道是否没有办法实现这样的东西，gpu 将用于计算而不是 cpu？考虑到，例如，在视频游戏中渲染时，显卡的延迟最小，
我知道有各种库可以利用显卡的强大功能，但不确定这是否是我需要的。我只发现了两种与此相关的材料，但正如我之前所说，我不确定它们是否完全有效。如果你知道好的图书馆，请分享这个。 https://archive.codeplex.com/?p=cudafy
https://www.codeproject.com/Articles/1116907/How-to-Use-Your-GPU-in-NET
另外，我想我很可能会尝试在 C# 中实现它。
这个问题对于它设想的使用场景相当模糊，但是为了从接受的答案中给出比“只是做不到，伙计”稍微更详细的答案，延迟和带宽之间总是存在权衡。究竟是一个问题还是另一个问题取决于应用程序。如果您想要在现场表演期间进行实时处理，这就是它的目的之一。如果您想要对录音进行类似 DAW 的后处理，那就在另一端了。
下面是最近一篇论文（Renney、Gaster 和 Mitchell“There and Back Again：GPU 加速数字音频的实用性”，NIME 2020）中的说明表，显示了使用 GPU 进行音频合成时的这种权衡。
物理模型合成器双向实时测试。
您会受到一端（缓冲区大小较高）的延迟和抖动以及另一端（缓冲区大小较低）带宽不足的挤压。
使用固定内存进行传输会对某些独立 GPU（尤其是 GPU）带来巨大的延迟差异。来自AMD家族，如下图所示：
固定内存与片上 GPU 几乎没有任何区别，而且它们在延迟方面也已经是王者，但在内部带宽和处理能力方面通常性能较低。
还有 API 引起的开销问题，这基本上算作应用程序的延迟。正如论文发现的那样，OpenCL 在这方面比 CUDA 更差（在 Nvidia 卡上）。
至于你真正的问题是那里有什么......没有那么多。TLDR：在众所周知的平台中，Csound 6 中有实验性的 CUDA 支持，仅作为源代码分发。（如果我需要说的话，那不是 C#。）
ROLI 将SOUL设想为类似 CUDA 的 API（实际上是语言），用于在 DSP 上运行音频任务，就像在 GPU 上加速图形一样。唉，ROLI 最近破产了，SOUL现在正处于深度冻结状态。因此，这可能暗示这种基于 PC 的硬件音频加速可能没有太大的市场，因此缺乏良好的工具和库是与此相伴的。
有较旧的 Faust 用于类似的合成任务（正如 SOUL 的目标），并且有一些 DSP 支持 Faust，例如 SHARC。但这与 GPU 基本上是不同的世界。Faust 不做 GPU，它的开发人员对添加支持也不太感兴趣。他们最近确实有针对FPGA 的 Faust的更多工作。一般来说，他们似乎更喜欢针对独立的嵌入式平台，您可以在该平台上制作动手仪器，而不是与 PC 连接的东西。以下是他们在这方面所支持的内容的最新（2020）概述。GPU 位于该论文的最后一节：
近年来，图形处理单元 (GPU) 越来越多地用于实时音频处理应用，利用其高度并行化来运行 DSP 算法，这些算法可以轻松划分为多个处理单元，例如模态混响 [19 ]、 ETC。
我们相信，FAUST 可以通过促进此类平台的编程在这方面发挥作用。我们在 2010 年通过开发 OpenCL 和 CUDA 后端做了一些实验。当时的结果并没有真正令人信服。现在 GPU 变得越来越强大，并且随着对可以利用其海量数据并行能力的 DSP 算法类别有了更好的了解，我们计划在未来再次研究这个主题。
他们在这方面引用的 2019 年 LAC 论文是由两名斯坦福大学 CCRMA 研究人员撰写的。值得一看的实际应用（数字波导）以及小型调查，其本身大约一页长，因此我不会在这里引用所有内容，但通常它对于物理模型等专业应用很有用乐器或大型扬声器阵列：
特雷比恩等。等[7] 使用模态合成为不同材质的物体之间的实时碰撞产生逼真的声音。注意到 IIR 滤波器传统上在 GPU 上表现不佳，因为依赖于先前状态不能很好地映射到 GPU 的并行特性，因此他们引入了一种变换，将其更改为线性卷积运算符并解锁时间轴并行性。[...]
Belloch 在 [9] 和 Belloch 等人中介绍了 GPU 加速的大规模并行过滤。等[10] 利用 GPU 加速在 96 个扬声器阵列上实现波场合成，其中包含近万个分数延迟房间滤波器和数千个抽头。针对不同的实时缓冲区大小和空间分区计算模拟声源的最大数量；通过 256 个样本缓冲区（44.1kHz 时为 5.8ms），可以在现场放置 18 到 198 个实时源。
Bilbao 和 Webb[11] 提出了一种 GPU 加速的定音鼓模型，在鼓内外的 3D 计算空间中合成 44.1kHz 的声音。GPU 方法使用无矩阵实现，比基于 MATLAB CPU、基于稀疏矩阵的原型获得 30 倍以上的加速，比单线程 C 代码基线获得超过 7.5 倍的加速。最大（也是计算成本最高）的鼓更新方程优化为每个样本 2.04 毫秒，其中瓶颈是鼓膜的线性系统更新。
对于更传统的合成技术，他们引用了一篇相当古老的论文，该论文在 GPU 上实时合成了数百万个正弦曲线，但他们指出，到目前为止，人们还没有找到那么多颗粒的应用程序。
据我所知，所有这些研究应用程序都是直接为 CUDA 等 GPU 计算 API 编写的，而不是在任何音频中间库中编写。所以这主要是一种“从头开始”的方法。斯坦福大学的论文相当清楚地说明了发生这种情况的原因：您经常需要诉诸 CUDA 分析工具来分析内存访问。
内存访问应该尽可能快地访问 RAM，并且我们需要注意内存对齐。虽然 CPU 代码确实受益于类似的优化，但当参数偏离理想范围时，GPU 算法的性能会迅速下降。
关于为最终用户概括此代码的另一个注意事项：在开发过程中，我们多次查阅了特定显卡的功能，以了解我们有多少寄存器，或者了解我们可以切片共享内存的各种方式。虽然这些参数可以在运行时从卡上查询，并且大多数更新、更强大的 GPU 包含旧资源的超集，但这并不能保证，例如，如果我们尝试在 GTX 480 上运行编译后的波导二进制文件从几代人开始，它就无法运行，因为我们请求了太多的共享内存。