Version
menu_open
Warning: you were redirected to the latest documentation corresponding to your major release ( 2023.1.8.8601 ). Should you wish to access your specific version's documentation, please download the offline documentation from the Audiokinetic Launcher and check the Offline Documentation option in Wwise Authoring.
Target Platform(s):
Wwise SDK 2023.1.8
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:

  • uSampleRate to the hardware preferred rate. This is usually 48 kHz or 44.1 kHz.
  • uNumSamplesPerFrame to the hardware preferred rate. This is usually in the order of 128, 192, or 240 samples, but can be higher depending on the device.
  • uNumRefillsInVoice to 4.

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.

On Android, when this occurs, Wwise will automatically increase the size of its internal buffer by a small amount in order to avoid further starvation. It will do so for every frame in which audio starvation occurs, until the buffer is just large enough to no longer cause starvation. At that point, Wwise has found the optimal balance between latency and CPU usage.

This process is relatively fast; audio glitches are usually heard only for a few milliseconds after the game first starts, or after the app is resumed from a background state.

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 hardware 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