Version
menu_open
Target Platform(s):

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 1024.
  • uNumRefillsInVoice to 4.

Advantages: This setup offers good protection against starvation on most devices. There are also many fewer constraints on the CPU usage of the audio design.
Disadvantages: It has 1024 * 4 samples of latency (around 86 ms), plus sync (0 to 21 ms), plus hardware processing (it depends).

Lowest Latency Settings

To initialize Wwise with the lowest latency, call AK::SoundEngine::GetDefaultSettings() and AK::SoundEngine::GetDefaultPlatformSettings(), then call AK::SoundEngine::GetFastPathSettings(). This will override the default settings with the device's preferences.

This 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 between 96 to 512 samples, depending on the device. Usually in the order of 128 or 240 samples.
  • Manually change uNumRefillsInVoice to 2.

Advantages: Latency is device-dependent, but the usual range would be 240 * 2 samples (10 ms), plus hardware (unknown).
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.

A Mid-point Between Minimum and Maximum Latency

Between the two setups described above lies a compromise that each game developer must find, depending on the target devices and audio design. You can change uNumSamplesPerFrame by an integer multiple and still use the fast audio path, when available. There is also a way to control the CPU overhead: if you double uNumSamplesPerFrame, Wwise behavioral overhead will be computed half as often.

uNumRefillsInVoice will need to be set to at least 3, usually 4 in most games, to have some headroom for CPU usage variations.

Advantages: CPU usage is not constrained by hardware. Audio rendering time can vary a lot, allowing for more complex and dynamic designs.
Disadvantages: CPU availability is not guaranteed. Therefore, higher buffering (latency) might be needed depending on the audio design and other usages, such as the rest of the game and other apps on the device.

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