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

Question

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

就上下文而言，假设在 Android 中播放音频剪辑的延迟为 150ms，即 SoundPool.play 在 T=0m 时执行，最终用户在 T=150ms 时听到声音。

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

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

Answer 1

设置播放需要更多时间，因为它必须初始化播放，以下操作需要路径

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

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

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

音量上下是对 AudioManager 的简单调用以调整通话音量。所以它的延迟应该低于播放/停止