我一直致力于将OpenSL用于Android的低延迟音频应用。到目前为止，我在三星Galaxy S5上实现的最低延迟是200ms（触摸到声音，通过点击和录制敲击声音然后是app声音来测量）。我想我可以通过改进一些内部app逻辑将其降低到160ms。现在，接收触摸的应用和获得该音频的回调之间有长达40ms的延迟。我想这是因为我没有音频时不断排队空缓冲区。这是不好的做法吗？当我尝试仅在出于某种原因存在音频时排队的方法时，我得到了音频伪像。
无论如何，我的问题是，在任何最新的Android设备上使用openSL从触摸到音频输出的最低可实现延迟是多少？ （我知道它在设备之间有所不同，但我想知道什么是低延迟的最佳设备，如果有的话，这个最低延迟的价值是什么？或者可能是最近设备的平均可获得的最小值？）。 / p>
Android: sound API (deterministic, low latency)
大约一年前的上述链接表明它大约在180ms范围内。这仍然是OpenSL最低的可能吗？建议的答案是，用于Android的音乐合成器获得了＆＃34;总输出延迟＆＃34;不到30毫秒。但是当我在三星Galaxy S5上运行时，它的声音延迟达到了200ms。那是什么＆＃34;总输出延迟＆＃34;指的是？我错过了什么吗？
如何进一步减少延迟？
感谢你们给我的任何帮助！
编辑：除了NEON或SSE指令外，我执行此处Low-latency audio playback on Android所述的所有内容，但我的处理时间少于此处所述的15％，因此不应该成为问题。我正在使用2 * PROPERTY_OUTPUT_FRAMES_PER_BUFFER短信排队一个缓冲区，用于立体声。这太高了吗？
答案 0 :(得分：3)
似乎我正在测试的设备，Galaxy S5没有android.hardware.audio.low-latency。这意味着openSL无法使用快速跟踪并导致高延迟。这真的很令人惊讶，因为该设备非常新，所以它应该支持这样的新功能。但是，尽管在我的应用程序中执行了所有必需的低延迟，但它在我正在测试的设备上会有很长的延迟。
来自android ndk openSL docs： ＆＃34;这些改进可通过OpenSL ES获得，用于声称功能＆＃34; android.hardware.audio.low_latency＆＃34;的设备实现。如果设备没有声明此功能但支持API级别9（Android平台版本2.3）或更高版本，那么您仍然可以使用OpenSL ES API，但输出延迟可能更高。仅当应用程序请求缓冲区计数为2或更多，以及与设备的本机输出配置兼容的缓冲区大小和采样率时，才使用较低的输出等待时间路径。＆＃34;
对于想知道您的应用是否是问题的人。请务必检查您正在测试的设备是否支持此功能。另请查看（ndk）/docs/opensles/index.html的“性能”部分以及问题中的链接
答案 1 :(得分：0)
有一个audio-echo样本，您可以查看它是否有帮助。当您为快速音频创建播放器时，不支持某些信号处理接口;如果您请求不支持的接口，即使您询问设备默认采样率，也会关闭快速音频。该示例适用于android L和M [未在其他人身上测试]