iOS 音频加速答案

【问题标题】：iOS audio accelerationiOS 音频加速
【发布时间】：2012-06-21 18:21:21
【问题描述】：

是否有人成功使用 OpenGLES2.0 着色器 (GLSL) 进行音频合成？

我已经在我的 iOS 应用程序中使用 vDSP 来加速音频，它提供了一个简单的 C 代码矢量指令集。 vDSP 的主要问题是您必须编写相当于面向向量的汇编语言，因为每个样本的主要循环被推入每个原始操作（向量加法，向量乘法）。将表达式编译到这些序列中是着色器语言为您自动化的本质。 OpenCL 在 iOS 中不公开。有趣的是 GLSL 是在运行时编译的，这意味着如果大部分声音引擎都可以在 GLSL 中，那么用户可以做出不平凡的补丁贡献。

【问题讨论】：

标签： ios audio opengl-es-2.0 signal-processing vdsp

【解决方案1】：

虽然 iOS GPU 着色器可以相对“快速”，但从 GPU 加载和恢复数据（纹理、处理的像素等）的路径足够慢，足以抵消使用 GLSL 带来的任何当前着色器计算效率。

对于实时合成，GPU 像素卸载路径的延迟远大于仅使用 CPU 合成提供 RemoteIO 的最佳音频响应延迟。例如显示帧速率（GPU 流水线锁定到的帧速率）低于最佳 RemoteIO 回调速率。在这些短音频缓冲区中没有足够的并行性来利用。

【讨论】：

我在波表合成的上下文中做当前的vDSP代码，理论上它实际上有很好的并行性。如果您将 4 个手指放在玻璃上，每个手指 3 个声音用于合唱失谐，每个音频缓冲区有 256 个样本。至于进出卡的传输，所有波表数据都将被预先加载，主要问题是我可以以什么速率可靠地使用新参数调用内核并将 256 个样本拉回以呈现为音频。
即：控制率约为 100hz（为语音样条设置新点），并可靠地获取足够的样本以覆盖该时间段。
在这个遥远的未来，我们现在拥有CVOpenGLESTextureCache，它可以让 GPU 和 CPU 访问相同的缓冲区，从而消除纯 GL 方法的昂贵来回.但是我无法评论延迟。顾名思义，它主要用于实时视频处理之类的东西，它往往以较大的步骤发生。