实时音频处理 - 延迟可行性检查答案

【问题标题】：Real-time Audio processing - latency feasibility check实时音频处理 - 延迟可行性检查
【发布时间】：2013-06-11 15:19:34
【问题描述】：

我有一个需要实时音频信号处理的应用概念，可以大致描述为：a) 对传入的音频进行采样（来自麦克风），b) 执行信号处理功能（例如滤波、傅立叶变换、滤波和操纵, 傅立叶逆变换) c) 播放（通过扬声器插孔）

我相信“端到端”往返时间 (a) 到 (c) 需要大约 2 到 5 毫秒，应用程序才能在现实世界中工作。

那么，我的问题是，这在当今一代的 iphone 和 android 手机上是否可行？

【问题讨论】：

5 毫秒，例如 44.1 kHz 将您的最大 FFT 长度限制为 220 个样本。
我相信只有 I/O 是 iOS 的顺序（非常粗略地说）。 Android 曾经更高，但新版本应该会更好。
@Oli Charlesworth - 如果只有用户“端到端”音频处理管道中的操作是 FFT，那就是真的。但是会有A/D，然后是OP提到的其他一些信号处理，最后是D/A。因此，对于 OP 中提到的 5ms 延迟预算，实际的 FFT 长度可能少于 220 个样本。
@goldenmean：当然。但我的观点是，这是 FFT 大小的绝对上限，以说明 5ms 有多短......

标签： audio signals real-time latency feasibility

【解决方案1】：

在 iOS 上，这是可能的，但不能保证。我已经设法在我的 iOS 应用程序中获得约 6 毫秒（22050 采样率，128 个样本缓冲区大小），该应用程序对语音输入进行实时处理。看看 Novocaine (https://github.com/alexbw/novocaine) - 它提供了对音频单元的良好封装并使编程更容易。

但是，请记住，即使您请求特定的缓冲区大小，iOS 在运行时也可能会根据资源限制决定以更长的时间间隔（=> 更高的延迟）发送更大的缓冲区。例如，如果您请求的缓冲区大小为 128（约 6 毫秒），那么您最终可能会在 12 毫秒时获得 256 个大小的缓冲区。您的应用必须考虑到这一点并相应地处理缓冲区。

不幸的是，在 Android 上，低延迟往返音频是一个更大的问题。这是因为延迟是由许多设备/制造商驱动的因素驱动的，例如硬件/驱动程序级别的缓冲区，并且这些因素因设备而异。你可以在这里找到关于这个长期存在的 Android 障碍的讨论：https://code.google.com/p/android/issues/detail?id=3434

我的建议是暂时忽略 Android，并在 iOS 设备上实施/验证您的信号处理算法。稍后，您可以考虑将它们移植到 Android。

【讨论】：