android - Android 播放、暂停/停止和设置音频音量的相对延迟

Question

我的问题是关于在 Android 中播放、暂停/停止和设置音频音量的相对延迟。具体来说:暂停/停止音频剪辑的延迟是否与播放音频剪辑的延迟相同或更低，同样，设置剪辑音量(或系统音量)的延迟是否与播放它的延迟相同或更低。

对于上下文，假设在 Android 中播放音频剪辑的延迟为 150 毫秒，即 SoundPool.play 在 T=0 分钟时执行，最终用户在 T=150 毫秒时听到声音。

在 T=200m 时，程序执行 SoundPool.pause。如果暂停延迟也是 150m，这意味着最终用户在听到 200m 的剪辑后，直到 T=350m 才会听到暂停。但是，如果暂停延迟为 50 米，那么声音将在 T=250 米处停止，而最终用户只走了 100 米。

显然延迟在设备之间不是恒定的、精确的或一致的，所以更准确地说，我真正想问的是 Android 是否使用单独的路径或技术来暂停/停止/更改音频音量(无论是程序- 特定或系统范围的音量)本质上比播放音频的方式延迟更低。

Answer 1

设置 Play 需要更多时间，因为它必须初始化 play 以下操作采用的路径

1. 找到媒体文件的MIME类型，这需要解析媒体格式并寻找特定的header
2. 初始化音频解码器(通常是硬件)，OMX解码器必须加载到内存中
3. 设置缓冲区，比如在解析器中分配 10 个缓冲区，在解码器中分配 10 个缓冲区。
4. 设置解析器和解码器与播放音频设备(扬声器)之间的路径
5. 播放发生在这一步，数据从解析器缓冲区流向解码器缓冲区，当解码器缓冲区已满时，OMX(解码器框架)将通知播放器引擎，引擎将缓冲区数据传递给 AudioManager -> AudioTrack 等。
6. 解码器将再次处理来自解析器缓冲区的数据，这个过程一直持续到 EOF 或用户按下暂停/停止

在暂停期间，延迟应该比播放低得多，因为只有数据交换暂停，但不会释放缓冲区。

在停止过程中buffer被释放，播放器也被释放，所以如果用户需要再次播放，需要做同样的过程再次播放。

音量调高和调低是简单调用AudioManager 来调整调用音量。所以它的延迟应该低于播放/停止