|
Wwise SDK 2024.1.1
|
Android音频延迟一直都是所有应用的问题之一。虽然通常延迟低于100ms，但有些设备的延迟高达150ms。
在最近的操作系统版本中，谷歌引入了“快速音频路径”。如果满足一些条件，这样做会旁通一些内部处理，极大地减少操作系统和硬件处理的延迟。总体延迟可以减少到几十毫秒。重要的是要注意到，并没有规定要求硬件厂商必须实现快速音频路径；所以，很多生产商不会去做。此外，有些设备没有真的实现快速通道，但会号称实现了。因此，游戏不能放心假设在终端用户的设备上有快速音频路径存在。如果您的游戏是针对广泛目标市场，则在设计游戏音频时不应该使用该功能。
一般来说，更低的延迟会引发更高的CPU消耗。RTPC更新的处理、游戏对象位置、以及其他游戏输入都是每帧进行的。因此，帧越小，处理进行得就越频繁。延迟和CPU占用之间的平衡点可以通过实验找到。没有什么死规矩。
Wwise 初始化设置控制延迟
有些设置会在Wwise SDK中控制音频延迟：
AkPlatformInitSettings::uSampleRate：使用的采样率。When set to 0 (the default), the hardware preferred rate is selected, allowing use of the fast audio path.AkPlatformInitSettings::uNumRefillsInVoice：预处理缓冲区数目。这是针对CPU可用性问题或中断的保护。AkInitSettings::uNumSamplesPerFrame：每缓冲区采样数。AkPlatformInitSettings::bEnableLowLatency: Whether the Android fast audio path is requested when initializing audio output streams.
默认设置，通用延迟
由 AK::SoundEngine::GetDefaultSettings() 和 AK::SoundEngine::GetDefaultPlatformInitSettings() 返回的默认设置在大部分情况下对大部分设备来说是“安全的”设置。使用这些会将：
uSampleRate设置成硬件偏好数值。这一般是48 kHz或44.1 kHz.uNumSamplesPerFrameto 512.uNumRefillsInVoice设置成4。AkPlatformInitSettings::bEnableLowLatencytotrue.
优势： 此设置将为支持的设备选择快速路径。对于音频设计的CPU占用限制也少得多。
劣势： 为了给 CPU 用量变化留出一些空间，需要预处理四帧的音频，可能会导致不需要设置余量的设备产生更高的延迟。
最低延迟设置
要想以最低延迟来初始化 Wwise，可调用 AK::SoundEngine::GetDefaultSettings() 和 AK::SoundEngine::GetDefaultPlatformSettings() ，然后将 uNumRefillsInVoice 手动改为 2。
优势： 可将延迟降到最低。
劣势： 可用CPU受限。分配给渲染音频的时间非常短，而且很容易被其他系统上的事件打断。音频设计的CPU开销（比如RTPCs、切换开关、定位、以及容器）会是一个问题，需要仔细监控。
假如将 uNumRefillsInVoice 设得太低，会发生什么？
在音频帧所需处理时间短到 CPU 无法及时完成处理时，会出现音频匮乏。此时，假如游戏不是在输出无声音频，用户可能会听到可辨的噼啪和毛刺噪声。
若无法接受这种毛刺现象，可通过如下方式禁用此行为：确保将 uNumRefillsInVoice 设成一个大到绝对不会导致匮乏的初始值。在大部分游戏中 uNumRefillsInVoice 需要至少设置成3，通常为4，这样能为CPU占用变化留出余量。
蓝牙的例外
正如Android程序员备注中所说，蓝牙设备不支持低延迟，也不支持使用快速路径。实际上，为了在蓝牙设备上拥有无故障的音频，缓冲必须更高，每一帧也必须更大。Wwise will detect the usage of a Bluetooth headset and will automatically reset the audio device to have 8,192 samples of latency, which is roughly 180 ms.