Android:OpenSL尽可能低的延迟

我一直在致力于使用OpenSL为Android开发一款低延迟音频应用程序。到目前为止，我在三星Galaxy S5上成功实现的最低延迟是200毫秒（触摸到声音，通过轻敲和录制轻敲声音，然后是应用程序声音来测量）。我想通过改进一些内部应用程序逻辑，我可以把它降低到160毫秒。现在，在应用程序接收触摸和获得该音频的回调之间有多达40毫秒的延迟。我想这是因为在没有音频的情况下，我一直在排队等待空缓冲区。这是坏习惯吗？不过，当我尝试仅当出于某种原因存在音频时才排队的方法时，我会得到音频伪影

无论如何，我的问题是，在任何最新的Android设备上，使用openSL从触摸屏到音频输出的最低延迟是多少？（我知道每个设备的延迟不同，但我想知道，如果有低延迟的设备，那么哪种设备是最好的，最低延迟的值是多少？或者最近设备的平均可获得最小延迟值是多少？）

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

如何进一步减少延迟

谢谢你能给我的任何帮助

---

编辑：除了霓虹灯或SSE指令外，我正在执行此处规定的所有操作，但我的处理时间少于此处规定的15%，所以这不应该是一个问题。我正在排队一个缓冲区，每个缓冲区有2个*属性输出帧，用于立体声。这是不是太高了？

我正在测试的设备，Galaxy S5没有android.hardware.audio.low-latency。这意味着openSL不能使用fast track，这将导致高延迟。这确实令人惊讶，因为该设备非常新，所以它应该支持这样的新功能。但是，尽管我做了所有必要的事情，使我的应用程序具有低延迟，但在我正在测试的设备上，它将具有高延迟

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

---

对于任何想知道你的应用程序是否有问题的人。确保检查您正在测试的设备是否支持此功能。还可以查看（ndk）/docs/opensles/index.html的性能部分以及问题中的链接。

有一个示例，您可以查看它是否有帮助。为快速音频创建播放器时，不支持某些信号处理接口；如果您请求不受支持的接口，即使您使用设备默认采样率请求，fast audio也将关闭。该示例适用于android L和M[未在其他设备上进行测试]

这个问题可能会吸引一些基于个人使用有限设备体验的轶事答案，而不是明显正确或错误的确定答案。因此，它似乎并不适合StackOverflow，因为这不是一个讨论论坛。不管怎样，你引用的数字听起来有点高。大约一年半前，当我运行延迟测试时，使用相同的测量方法，我在XPeria Z上得到了100毫秒以下的时间？有一些快速模式我必须激活吗？我使用的simplebufferedqueueplayer在排队的缓冲区中有（PROPERTY_OUTPUT_FRAMES_PER_BUFFER*2）短路，音频数据和播放器的PROPERTY_OUTPUT_SAMPLE_RATE。我使用立体声，这就是为什么*2表示短裤的数量。我能想到的唯一一件事是我没有使用NEON或SSE指令，但我的处理时间不到播放时间的15%，延迟仍然很高。这令人失望，好消息，因为我正在考虑购买S5It不支持OpenSL低延迟，但在这些设备上可能有其他方式获得它，我不知道。