【发布时间】:2014-07-11 00:52:15
【问题描述】:
我一直致力于将 OpenSL 用于 Android 的低延迟音频应用程序。到目前为止,我在三星 Galaxy S5 上设法实现的最低延迟为 200 毫秒(触摸到声音,通过点击和录制点击声音,然后是应用程序声音来测量)。我想我可以通过改进一些内部应用程序逻辑将它降低到 160 毫秒。现在,在应用程序接收到触摸和获取该音频的回调之间存在长达 40 毫秒的延迟。我认为这是因为当没有音频时,我会不断地排队空缓冲区。这是不好的做法吗?但是,当我尝试仅在由于某种原因有音频时才排队的方法时,我得到了音频伪像。
无论如何,我的问题是,在任何最新的 Android 设备上,使用 openSL 从触摸到音频输出的最低延迟是多少? (我知道它因设备而异,但我想知道什么是低延迟的最佳设备(如果有的话),这个最低延迟的价值是多少?或者也许是最近设备可获得的平均最小值?)。
Android: sound API (deterministic, low latency)
大约一年前的上述链接表明它在 180 毫秒范围内。这对于 OpenSL 来说仍然是最低的吗?推荐的答案说,Android 的音乐合成器获得了低于 30 毫秒的“总输出延迟”。但是当我在三星 Galaxy S5 上运行它时,它的声音延迟为 200 毫秒。 “总输出延迟”指的是什么?我错过了什么吗?
如何进一步减少延迟?
感谢您能给我的任何帮助!
编辑:除了 NEON 或 SSE 指令外,我正在执行此处 Low-latency audio playback on Android 中所述的所有操作,但我的处理时间少于此处所述的 15%,因此这应该不是问题。我正在将一个带有 2*PROPERTY_OUTPUT_FRAMES_PER_BUFFER 短裤的缓冲区排入队列以获取立体声。是不是太高了?
【问题讨论】:
-
这个问题很可能会根据个人使用有限设备的经验来吸引轶事答案,而不是明确的正确或错误的答案。因此它似乎并不适合 StackOverflow,因为这不是一个讨论论坛。无论如何,你引用的那些数字听起来有点高。大约一年半前,当我在 XPeria Z 上运行延迟测试时,使用相同的测量方法得到的时间低于 100 毫秒。
-
使用openSL?我必须激活一些快速模式吗?我在入队的缓冲区中使用带有 (PROPERTY_OUTPUT_FRAMES_PER_BUFFER * 2) 短裤的 simplebufferedqueueplayer,并为音频数据和播放器使用 PROPERTY_OUTPUT_SAMPLE_RATE。我使用的是立体声,这就是为什么 * 2 代表短裤的数量。我唯一能想到的我没有做的就是使用NEON或SSE指令,但是我的处理时间不到播放时间的15%,延迟仍然很高。
标签: android performance audio low-latency opensl