Version
menu_open
Target Platform(s):
Wwise SDK 2024.1.1
Controlling Latency on Android

Android audio latency has always been an issue for all applications. Some devices exhibit up to 150 ms of latency, although the usual latency is below 100 ms.

In recent OS versions, Google introduced the "fast audio path." This bypasses some of the internal processing if some conditions are met, drastically reducing the latency of the OS and hardware processing. Overall latency can be reduced to a few dozen milliseconds. It is important to note that it is not mandatory for the hardware manufacturers to implement the fast audio path; so, many do not. Furthermore, some devices report a fast path without it actually being implemented. Therefore, a game cannot rely on the existence of the fast audio path on the end-user's devices. If your game is for a wide target market, you should design your game audio without using this feature.

Generally, a lower latency will incur a higher CPU cost. The processing of RTPC updates, game object positions, and other game inputs is done on a per-frame basis. Therefore, with a smaller frame, this is processed more often. The balance between latency and CPU usage can only be found through experimentation. There is no hard rule.

Wwise Initialization Settings Controlling Latency

A few settings will control the latency of audio in the Wwise SDK:

Default Settings, One-size-fits-all Latency

The default settings returned by AK::SoundEngine::GetDefaultSettings() and AK::SoundEngine::GetDefaultPlatformInitSettings() are "safe" settings for most devices in most conditions. Using those will set:

Advantages: This setup will select the fast path on devices that support it. There are also many fewer constraints on the CPU usage of the audio design.
Disadvantages: Four frames of audio are pre-processed to allow some room in CPU variation, which can cause higher latency on devices that may not need the headroom.

Lowest Latency Settings

To initialize Wwise with the lowest latency, call AK::SoundEngine::GetDefaultSettings() and AK::SoundEngine::GetDefaultPlatformSettings(), then manually change uNumRefillsInVoice to 2.

Advantages: Lowest latency possible.
Disadvantages: Available CPU is limited. The time allotted to rendering audio is very short and can be easily disturbed by other events on the system. CPU overhead of audio designs (such as RTPCs, Switches, Positioning, and containers) is a concern and needs to be monitored carefully.

What happens when uNumRefillsInVoice is set too low ?

When the time required to process an audio frame is lower than what the CPU can handle, audio starvation occurs. At this point, users may hear audible pops and glitches if the game is not outputting silence.

If this glitching is unacceptable, you may opt out of this behavior by making sure to set uNumRefillsInVoice to an initial value large enough to never cause starvation. uNumRefillsInVoice will need to be set to at least 3, usually 4 in most games, to have some headroom for CPU usage variations.

The Bluetooth exception

As said in Android's programmer's notes, Bluetooth devices cannot be low latency or use the fast path. In fact, to have glitchless audio with a Bluetooth device, the buffering must be a lot higher and the frames larger. 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.

Was this page helpful?

Need Support?

Questions? Problems? Need more info? Contact us, and we can help!

Visit our Support page

Tell us about your project. We're here to help.

Register your project and we'll help you get started with no strings attached!

Get started with Wwise