Android:OpenSL 尽可能低的延迟

Question

我一直致力于将 OpenSL 用于 Android 的低延迟音频应用。到目前为止，我在 Samsung Galaxy S5 上实现的最低延迟是 200 毫秒(触摸到声音，通过点击和记录点击声音，然后是应用声音来测量)。我想我可以通过改进一些内部应用程序逻辑将它降低到 160 毫秒。现在，应用程序接收触摸和获取该音频的回调之间最多有 40 毫秒的延迟。我认为这是因为当没有音频时，我一直在排队空缓冲区。这是不好的做法吗？但是，当我尝试仅在有音频时出于某种原因才排队的方法时，我得到了音频伪像。

无论如何，我的问题是，在任何最新的 Android 设备上使用 openSL 从触摸到音频输出可实现的最低延迟是多少？ (我知道它因设备而异，但我想知道什么是低延迟的最佳设备，如果有的话，这个最低延迟的值(value)是多少？或者也许是最近设备的平均可获得的最小值？)。

Android: sound API (deterministic, low latency)

大约一年前的上述链接表明它在 180 毫秒范围内。这仍然是 OpenSL 的最低可能吗？推荐的答案是，Android 版音乐合成器获得了 30 毫秒以下的“总输出延迟”。但是当我在三星 Galaxy S5 上运行它时，它有 200 毫秒的触摸声音延迟。 “总输出延迟”指的是什么？我错过了什么吗？

如何进一步降低延迟？

感谢您能给我的任何帮助!

编辑:我正在做这里所说的一切Low-latency audio playback on Android除了 NEON 或 SSE 说明，但我的处理时间少于那里规定的 15%，所以这应该不是问题。我正在排队一个缓冲区，其中包含 2*PROPERTY_OUTPUT_FRAMES_PER_BUFFER 短裤用于立体声。是不是太高了？

Answer 1

看来我正在测试的设备 Galaxy S5 没有 android.hardware.audio.low-latency。这意味着 openSL 无法使用快速 channel ，并且会导致高延迟。这真的很令人惊讶，因为该设备非常新，所以它应该支持这样的新功能。但是，尽管在我的应用程序中做了所有需要的低延迟，但它在我正在测试的设备上会有高延迟。

来自 android ndk openSL 文档:“这些改进可通过 OpenSL ES 获得，适用于声称具有“android.hardware.audio.low_latency”功能的设备实现。如果设备未声明此功能但支持 API 级别 9(Android 平台版本 2.3)或更高版本，则您可以仍然使用 OpenSL ES API，但输出延迟可能更高。仅当应用程序请求缓冲区计数为 2 或更多，并且缓冲区大小和采样率与设备的 native 输出配置兼容时，才使用较低的输出延迟路径”

对于任何想知道您的应用是否有问题的人。请务必检查您正在测试的设备是否支持此功能。另请查看 (ndk)/docs/opensles/index.html 的性能部分和问题中的链接