android - Android 上的低延迟音频播放

Question

我目前正在尝试最小化一个简单应用程序的音频延迟：

我在 PC 上有一个视频，我正在通过 RTP 将视频的音频传输到移动客户端。使用非常相似的缓冲算法，我可以在 iOS 上实现 90ms 的延迟，但在 Android 上却是可怕的 ±180ms。

我猜这种差异源于Android 上众所周知的延迟问题。

然而，在阅读了一会之后，我发现了这篇文章，其中指出：

1. 自 Android 4.1/4.2 起，某些设备可以使用低延迟音频。

2. 使用 libpd 可以实现低延迟音频，它是 Android 的纯数据库。

我有 2 个问题，与这 2 个陈述直接相关：

1. 在哪里可以找到有关 Jellybean 中新的低延迟音频的更多信息？这就是我能找到的全部，但它非常缺乏具体的信息。这些更改对我来说应该是透明的，还是我应该实施一些新的类/API 调用以让我注意到我的应用程序中的任何更改？我正在使用 AudioTrack API，我什至不确定它是否应该从这种改进中受益，或者我是否应该研究一些其他的音频播放机制。

2. 我应该考虑使用 libpd 吗？在我看来，这是实现更低延迟的唯一机会，但由于我一直认为 PD 是一种音频合成实用程序，它真的适合从网络流中抓取帧并播放它们的项目吗？ ? 我并没有真正进行任何合成。我走错路了吗？

作为附加说明，在有人提到 OpenSL ES 之前，这篇文章非常清楚地表明，使用它应该不会改善延迟：

“由于 OpenSL ES 是本机 C API，调用 OpenSL ES 的非 Dalvik 应用程序线程没有与 Dalvik 相关的开销，例如垃圾收集暂停。但是，除此之外，使用 OpenSL ES 没有额外的性能优势。在特别是，使用 OpenSL ES 不会导致比平台通常提供的更低的音频延迟、更高的调度优先级等。”

Answer 1

为了在 Android 4.2.2 版本上实现最低延迟，您应该执行以下操作，从最不明显到最明显排序：

1. 如果可能，请选择支持 FEATURE_AUDIO_PRO 的设备，否则选择支持 FEATURE_AUDIO_LOW_LATENCY 的设备。（“低延迟”是 50ms 一种方式；pro 是 <20ms 往返。）

2. 使用 OpenSL。Dalvik GC 的摊销成本很低，但是当它运行时，它需要的时间比低延迟音频线程所允许的要多。

3. 在缓冲区队列回调中处理音频。系统在比普通用户模式线程具有更有利调度的线程中运行缓冲区队列回调。

4. 将缓冲区大小设为 AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER) 的倍数。否则，您的回调偶尔会在每个时间片中收到两次调用，而不是一次。除非您的 CPU 使用率真的很低，否则这可能最终会出现故障。（在 Android M 上，完全使用系统缓冲区大小非常重要，因为缓冲区处理代码中存在错误。）

5. 使用 AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE) 提供的采样率。否则，您的缓冲区会绕过系统重采样器。

6. 永远不要在缓冲区回调中进行系统调用或锁定同步对象。如果必须同步，请使用无锁结构。为获得最佳结果，请使用完全无等待的结构，例如单读单写环形缓冲区。许多开发人员都犯了这个错误，最终会出现不可预测且难以调试的故障。

7. 使用向量指令，例如 NEON、SSE 或目标处理器上的任何等效指令集。

8. 测试和测量您的代码。跟踪运行所需的时间——并记住，您需要知道最坏情况下的性能，而不是平均值，因为最坏情况是导致故障的原因。并且要保守。您已经知道，如果处理音频比播放音频花费更多时间，您将永远无法获得低延迟。但在 Android 上，这一点更为重要，因为 CPU 频率波动很大。您可以将 60-70% 的 CPU 用于音频，但请记住，这会随着设备变热或变冷，或者随着 wifi 或 LTE 无线电的启动和停止等等而改变。

低延迟音频不再是 Android 的新功能，但它仍然需要对硬件、驱动程序、内核和框架进行特定于设备的更改才能实现。这意味着您可以从不同的设备中获得很多不同的延迟，并且考虑到 Android 手机的销售价格有多少不同，可能总会存在差异。查找 FEATURE_AUDIO_PRO 或 FEATURE_AUDIO_LOW_LATENCY 以识别满足您的应用所需延迟标准的设备。

Answer 2

使用 OpenSL ES 时，您应该满足以下要求才能在 Jellybean 和更高版本的 Android 上获得低延迟输出：

• 音频应该是单声道或立体声、线性 PCM。

• 音频采样率应该与输出的本机采样率相同（这在某些设备上实际上可能不需要，因为如果供应商配置FastMixer 它可以重新采样。但在我的测试中我得到了非常明显的）中从 44.1 到 48 kHz 上采样时的伪影FastMixer。

• 您BufferQueue应该至少有 2 个缓冲区。（此后此要求已放宽。请参阅Glenn Kasten 的此提交。我不确定它首次出现在哪个 Android 版本中，但猜测是 4.4）。

• 您不能使用某些效果（例如混响、低音增强、均衡、虚拟化……）。

如果可能，SoundPool该类还将尝试在AudioTrack内部使用 fast （与上述相同的标准适用，但BufferQueue部分除外）。

Answer 3

从您第 1 点的链接：

“低延迟音频

Android 4.2 改进了对低延迟音频播放的支持，从 Android 4.1 版本中使用 OpenSL ES、Soundpool 和音调生成器 API 对音频输出延迟所做的改进开始。这些改进取决于硬件支持——提供这些低延迟音频功能的设备可以通过硬件功能常量来宣传它们对应用程序的支持。”

您的完整引文：

“表现

由于 OpenSL ES 是原生 C API，调用 OpenSL ES 的非 Dalvik 应用程序线程没有与 Dalvik 相关的开销，例如垃圾收集暂停。但是，除此之外，使用 OpenSL ES 并没有额外的性能优势。特别是，使用 OpenSL ES 不会导致比平台通常提供的更低的音频延迟、更高的调度优先级等。另一方面，随着 Android 平台和特定设备实现的不断发展，OpenSL ES 应用程序有望从未来的任何系统性能改进中受益。”

因此，与驱动程序和硬件通信的 api 是 OpenSl（与 Opengl 处理图形的方式相同）。不过，早期版本的 Android 在驱动程序和/或硬件方面的设计很糟糕。这些问题已在 4.1 和 4.2 版本中得到解决和纠正，因此如果 hd 有能力，您可以使用 OpenSL 获得低延迟。

同样，从 puredata library 网站的这篇注释可以明显看出，该库使用 OpenSL 本身来实现低延迟：

兼容设备的低延迟支持 适用于 Android 的最新版本 Pd（截至 2012 年 12 月 28 日）支持兼容 Android 设备的低延迟音频。更新副本时，请确保从 GitHub 拉取 pd-for-android 和 libpd 子模块的最新版本。

在撰写本文时，Galaxy Nexus、Nexus 4 和 Nexus 10 为音频输出提供了低延迟轨道。为了达到低延迟轨道，应用程序必须使用 OpenSL，并且必须以正确的采样率和缓冲区大小运行。这些参数取决于设备（Galaxy Nexus 和 Nexus 10 以 44100Hz 运行，而 Nexus 4 以 48000Hz 运行；每个设备的缓冲区大小不同）。

按照惯例，Pd for Android 尽可能多地涵盖所有这些复杂性，提供对新低延迟功能的访问，同时保持与早期版本的 Android 向后兼容。在底层，Pd for Android 的音频组件将在 Android 2.3 及更高版本上使用 OpenSL，而在 Android 2.2 及更早版本上使用 Java 中的旧 AudioTrack/AudioRecord API。

Answer 4

那些对 Android 的 10 毫秒问题（即 Android 上的低延迟音频）更感兴趣的人。我们 Superpowered 创建了 Android 音频路径延迟解释器。请看这里：

http://superpowered.com/androidaudiopathlatency/#axzz3fDHsEe56

Answer 5

另一个使用的音频延迟和缓冲区大小数据库：

http://superpowered.com/latency/#table

源代码：

https://github.com/superpoweredSDK/SuperpoweredLatency

Answer 6

有一个新的 C++ 库双簧管有助于减少音频延迟。我在我的项目中使用过它并且效果很好。它具有以下功能，有助于减少音频延迟：

• 自动延迟调整
• 选择音频 API（API 16+ 上的 OpenSL ES 或 API 27+ 上的 AAudio）

Answer 7

测量 sampleRate 和 bufferSize 的应用程序：https ://code.google.com/p/high-performance-audio/source/checkout和http://audiobuffersize.appspot.com/结果数据库