控制Android上的延迟
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设置成1024。 -
uNumRefillsInVoice设置成4。
优势：这一设置能在大部分设备上比较好地防止匮乏。对于音频设计的CPU占用限制也少得多。
劣势：它有长度为 1024 * 4 个采样点的延迟（大约86ms），加上同步延迟（0到21ms），再加上硬件处理延迟（看情况）。
最低延迟设置
想要用最低延迟来初始化Wwise，就调用 \ c AK::SoundEngine::GetDefaultSettings() 和 AK::SoundEngine::GetDefaultPlatformSettings()，然后再调用 AK::SoundEngine::GetFastPathSettings()。这会用设备偏好来取代默认设置。
这会将：
-
uSampleRate设置成硬件偏好数值。这一般是48 kHz或44.1 kHz. -
uNumSamplesPerFrame设置成硬件偏好数值。这个值介于96到512个采样之间，视设备而定。通常大约是128或240个采样点。-uNumRefillsInVoice手动改为2。
优势：延迟视设备而定，但通常范围是240 * 2个采样（10 ms），加上硬件（未知）。
劣势：可用CPU受限。分配给渲染音频的时间非常短，而且很容易被其他系统上的事件打断。音频设计的CPU开销（比如RTPCs、切换开关、定位、以及容器）会是一个问题，需要仔细监控。
最小和最大延迟的中间点
根据目标设备和音频设计，在上述两种设置中间有一个折衷点，每名游戏程序员必须找到这个折衷点。您可以将 uNumSamplesPerFrame 改为整数倍，并且只要有条件用时就仍然可以用快速音频路径。还有一种方式可以控制CPU开销：如果您将uNumSamplesPerFrame改成原来的两倍，, Wwise行为开销的计算频率将降低一半。
在大部分游戏中uNumRefillsInVoice 需要至少设置成3，通常为4，这样能为CPU占用变化留出余量。
优势：CPU占用不受硬件限制。音频渲染时间可以有很大变化，从而允许更复杂更动态的设计。
劣势：CPU可用性无法保证。因此根据音频设计和其它占用（比如游戏中的其它和设备上的其它应用），可能需要更高的缓冲（延迟）。
蓝牙的例外
正如Android程序员备注中所说，蓝牙设备不支持低延迟，也不支持使用快速路径。实际上，为了在蓝牙设备上拥有无故障的音频，缓冲必须更高，每一帧也必须更大。Wwise将会检测蓝牙耳机的占用，并且会自动重置音频硬件来得到长度为8192个采样点的延迟，大约180ms。