OpenSL vs AudioTrack on Android API 26+ (avoiding AAudio)

FMOD Engine
1

I’m using the FMOD Core API on Android. On some devices, System_Init() takes 400 ms or more when the output is AAudio. For my case, I prefer to avoid AAudio for now.

That leaves me with OpenSL or AudioTrack. I prefer OpenSL because it offers finer granularity, but I’m not sure if it is safe to use it on every device my app can run on (API 26+).

Is it safe to always use OpenSL on API 26+ devices? If not, is there a way to ask FMOD which one (OpenSL vs AudioTrack) is better for the current device, like calling init with AUTODETECT but excluding AAudio? If not, what criteria should I use to decide between OpenSL and AudioTrack?

Thanks!

2

Hi,

There was a known issue with slow AAudio start up times which has been solved in the most recent release: FMOD Engine | Welcome Revision History. Would it be possible to update to the latest to confirm if the issue persists?

3

I’m currently using FMOD Engine 2.03.09, which according to the changelog already includes the fix for “slow startup times when using AAudio.”

On a Pixel 9A, AAudio still takes around 350 ms to initialize, while OpenSL only takes about 50 ms.

I understand the difference may not be huge, but AAudio doesn’t provide any clear advantage for my use case, and I need to minimize initialization time as much as possible.

4

Thank you for confirming.

Are you able to reproduce the issue with the included android API examples in the FMOD Android Engine download: fmodstudioapi20309android\api\core\examples\androidstudio\cmake\play_sound
How are you testing the initialization time? Any reproduction steps would be great!

5

Thank you. I reproduced it using the sample you mentioned. I added simple logging around System::init() and switched the output explicitly via System::setOutput().

Changes in play_sound.cpp:

#include <android/log.h>
#define LOGI(...) __android_log_print(ANDROID_LOG_INFO, "FMODPlaySound", __VA_ARGS__)

    // in FMOD_Main():

    FMOD_OUTPUTTYPE desiredOutput = FMOD_OUTPUTTYPE_OPENSL; // or FMOD_OUTPUTTYPE_AAUDIO
    result = system->setOutput(desiredOutput);
    ERRCHECK(result);

    LOGI("[Init] About to call system->init(32, FMOD_INIT_NORMAL, ...) with desiredOutput=%d", (int)desiredOutput);

    result = system->init(32, FMOD_INIT_NORMAL, extradriverdata);
    ERRCHECK(result);

    LOGI("[Init] Finished system->init()");

(And linked -llog in Android.mk.)

Logs

AAudio: ~519 ms (961 − 442):

2025-10-13 17:19:40.442 22172-22233 FMODPlaySound          org.fmod.example                     I  [Init] About to call system->init(32, FMOD_INIT_NORMAL, ...) with desiredOutput=18
2025-10-13 17:19:40.961 22172-22233 FMODPlaySound          org.fmod.example                     I  [Init] Finished system->init()

OpenSL: ~47 ms (270 − 223):

2025-10-13 17:22:00.223 23163-23197 FMODPlaySound          org.fmod.example                     I  [Init] About to call system->init(32, FMOD_INIT_NORMAL, ...) with desiredOutput=12
2025-10-13 17:22:00.270 23163-23197 FMODPlaySound          org.fmod.example                     I  [Init] Finished system->init()

This matches what I see in my app: AAudio ~500 ms vs OpenSL ~50 ms on this device. For my use-case I’m optimizing cold start, and I don’t see a functional advantage from AAudio here.

1 Like
6

Thank you for testing that and sharing your code.

I have been able to reproduce the same times. I will pass this info on to our development team. However, I will note our docs which addresses latency on Android: FMOD Engine | Platforms Android - Audio Latency.

As OpenSl has been deprecated: https://developer.android.com/ndk/guides/audio/opensl, I cannot say that it will be safe on all devices. You could attempt to initialize the FMOD system with OpenSL and on failure resort to AAudio?

Unfortunately, you cannot filter outputs when using AUTODETECT, I could suggest this to our development team to look into however.

I will link to a post where some options for dealing with latency were discussed: High latency with AAudio - #2 by jeff_fmod.

7

Thanks for the detailed reply, and for the link about latency.

Just to clarify, my concern here isn’t about latency during playback, but rather the initialization time of the FMOD system.

For now, I’ll continue using OpenSL, with a fallback to AUTODETECT if either setOutput() or init() return an error. That seems like the safest balance for the moment.

It would be great if future versions could either match the initialization speed between AAudio and OpenSL, or provide a way to automatically skip AAudio during output selection.

Thanks again for your help and for forwarding the info to the dev team.