Android音频延迟一直都是所有应用的问题之一。虽然通常延迟低于100ms，但有些设备的延迟高达150ms。

在最近的操作系统版本中，谷歌引入了“快速音频路径”。如果满足一些条件，这样做会旁通一些内部处理，极大地减少操作系统和硬件处理的延迟。总体延迟可以减少到几十毫秒。重要的是要注意到，并没有规定要求硬件厂商必须实现快速音频路径；所以，很多生产商不会去做。此外，有些设备没有真的实现快速通道，但会号称实现了。因此，游戏不能放心假设在终端用户的设备上有快速音频路径存在。如果您的游戏是针对广泛目标市场，则在设计游戏音频时不应该使用该功能。

一般来说，更低的延迟会引发更高的CPU消耗。RTPC更新的处理、游戏对象位置、以及其他游戏输入都是每帧进行的。因此，帧越小，处理进行得就越频繁。延迟和CPU占用之间的平衡点可以通过实验找到。没有什么死规矩。

Wwise 初始化设置控制延迟

有些设置会在Wwise SDK中控制音频延迟：

• AkPlatformInitSettings::uSampleRate：使用的采样率。如果设置成硬件偏好的数值（以及每帧采样），就可以选择音频快速路径。
• AkPlatformInitSettings::uNumRefillsInVoice：预处理缓冲区数目。这是针对CPU可用性问题或中断的保护。
• AkInitSettings::uNumSamplesPerFrame：每缓冲区采样数。如果设置成硬件偏好的大小（以及采样率），就可以选择音频快速路径。

默认设置，通用延迟

由 AK::SoundEngine::GetDefaultSettings() 和 AK::SoundEngine::GetDefaultPlatformInitSettings() 返回的默认设置在大部分情况下对大部分设备来说是“安全的”设置。使用这些会将：

• uSampleRate 设置成硬件偏好数值。这一般是48 kHz或44.1 kHz.
• uNumSamplesPerFrame 设置成硬件偏好数值。通常约为 128、192 或 240 个采样，有些设备可能会高些。
• uNumRefillsInVoice 设置成4。

优势： 此设置将为支持的设备选择快速路径。对于音频设计的CPU占用限制也少得多。
劣势： 为了给 CPU 用量变化留出一些空间，需要预处理四帧的音频，可能会导致不需要设置余量的设备产生更高的延迟。

最低延迟设置

要想以最低延迟来初始化 Wwise，可调用 AK::SoundEngine::GetDefaultSettings() 和 AK::SoundEngine::GetDefaultPlatformSettings() ，然后将 uNumRefillsInVoice 手动改为 2。

优势： 可将延迟降到最低。
劣势： 可用CPU受限。分配给渲染音频的时间非常短，而且很容易被其他系统上的事件打断。音频设计的CPU开销（比如RTPCs、切换开关、定位、以及容器）会是一个问题，需要仔细监控。

假如将 uNumRefillsInVoice 设得太低，会发生什么？

在音频帧所需处理时间短到 CPU 无法及时完成处理时，会出现音频匮乏。此时，假如游戏不是在输出无声音频，用户可能会听到可辨的噼啪和毛刺噪声。

在 Android 上出现这种情况时，Wwise 会自动地略微增大其内部缓冲区，以免匮乏情况变得更加严重。它会针对出现音频匮乏的每一帧执行此操作，直到缓冲区足够大，不再导致匮乏问题。此时，Wwise 会在延迟和 CPU 用量之间达到最佳平衡。

这个过程相对较短；在游戏首次启动后或应用从后台运行状态恢复后，一般只会出现几毫秒的音频毛刺噪声。

若无法接受这种毛刺现象，可通过如下方式禁用此行为：确保将 uNumRefillsInVoice 设成一个大到绝对不会导致匮乏的初始值。在大部分游戏中 uNumRefillsInVoice 需要至少设置成3，通常为4，这样能为CPU占用变化留出余量。

蓝牙的例外

正如Android程序员备注中所说，蓝牙设备不支持低延迟，也不支持使用快速路径。实际上，为了在蓝牙设备上拥有无故障的音频，缓冲必须更高，每一帧也必须更大。Wwise将会检测蓝牙耳机的占用，并且会自动重置音频硬件来得到长度为8192个采样点的延迟，大约180ms。