Lag when calling FMOD_System_Init in 2.02.07 (vs 1.10.20)

Hello.

I was using FMOD core (Android) 1.10.20, and now I’ve updated to 2.02.07 and the first time I play an audio (calling also to FMOD_System_Create and FMOD_System_Init) there is a noticeable lag (not noticeable with 1.10.20). Analyzing the Logcat, I see that there is a 200 ms difference between these 2 lines:

2022-06-13 09:19:26.994 D/AAudioStream: setState(s#25) from 2 to 11
2022-06-13 09:19:27.197 D/AAudioStream: setState(s#25) from 11 to 11

Is there any way to reduce such lag?

(I’m using a Pixel 6 Pro)

Thank you

EDIT:

I’ve just tested 2.02.07 using AudioTrack (instead of AAudio) and the lag is gone. But when using AudioTrack in 2.02.07 a new problem arises: FMOD_Channel_GetPosition is not as accurate as with 1.10.20 (or 2.02.07 with AAudio). It returns the same position although I’m calling it at different times. These are the positions I’m getting at different times:

2.02.07 with AAudio
2022-06-13 10:00:29.793: 0
2022-06-13 10:00:29.826: 43
2022-06-13 10:00:29.859: 64
2022-06-13 10:00:29.892: 107
2022-06-13 10:00:29.925: 128
2022-06-13 10:00:29.958: 171
2022-06-13 10:00:30.022: 235
2022-06-13 10:00:30.056: 277
2022-06-13 10:00:30.135: 341
2022-06-13 10:00:30.173: 384
2022-06-13 10:00:30.206: 427
2022-06-13 10:00:30.239: 448

2.02.07 with AudioTrack
2022-06-13 10:02:17.363: 0
2022-06-13 10:02:17.396: 43
2022-06-13 10:02:17.430: 43
2022-06-13 10:02:17.466: 107
2022-06-13 10:02:17.499: 107
2022-06-13 10:02:17.532: 171
2022-06-13 10:02:17.565: 235
2022-06-13 10:02:17.599: 235
2022-06-13 10:02:17.633: 299
2022-06-13 10:02:17.667: 299
2022-06-13 10:02:17.700: 341
2022-06-13 10:02:17.733: 341

1.10.20 AudioTrack
2022-06-13 10:04:08.149: 0
2022-06-13 10:04:08.182: 43
2022-06-13 10:04:08.215: 64
2022-06-13 10:04:08.248: 107
2022-06-13 10:04:08.282: 128
2022-06-13 10:04:08.315: 171
2022-06-13 10:04:08.348: 213
2022-06-13 10:04:08.381: 235
2022-06-13 10:04:08.415: 256
2022-06-13 10:04:08.454: 299
2022-06-13 10:04:08.487: 341
2022-06-13 10:04:08.522: 384

As you can see, using 2.02.07 with AudioTrack gives duplicated positions at different times. It’s not happening with AAudio or when using 1.10.20 with AudioTrack.

So, is it possible to fix either the init lag with AAudio or the problem with FMOD_Channel_GetPosition when using AudioTrack in 2.02.07?

Thank you

I have not been able to find any meaningful difference in duration between a sound playing for the first time and a sound played any other time. Neither have I found any noticeable lag or seen any repeated values coming from FMOD_Channel_GetPosition.
Are you just using the Core API or are you using the Studio API as well?
Do these issues reproduce for you in the Android examples?

Thank you for your response.

I am using Core API only. I can reproduce both issues using FMOD 2.02.07 and the “play_sound” example: You can see the 200ms (not much, but noticeable) difference between the lines I am pasting below. They appear after calling system->init():

2022-06-27 10:16:38.189 30767-30848/org.fmod.example D/AAudioStream: setState(s#1) from 2 to 11
2022-06-27 10:16:38.396 30767-30848/org.fmod.example D/AAudioStream: setState(s#1) from 11 to 11

About the getPosition problem, it is also reproducible with the play_sound example. In such example, I modified this line:

Common_Sleep(50);

with this one:

Common_Sleep(16);

so now it updates at about 60 frames per second rate and the issue is more noticeable. Then I added a log print at the end of the main loop, so it will display the playing position in logcat:

if (playing) {
     __android_log_print(ANDROID_LOG_DEBUG, "FMOD", "ms = %d", ms);
}

In order to get __android_log_print working I also added #include <android/log.h>. And also LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog in Android.mk

The result when playing the drumloop sound is this (using AAudio):

2022-06-27 10:42:25.281 678-833/org.fmod.example D/FMOD: ms = 0
2022-06-27 10:42:25.297 678-833/org.fmod.example D/FMOD: ms = 21
2022-06-27 10:42:25.314 678-833/org.fmod.example D/FMOD: ms = 43
2022-06-27 10:42:25.330 678-833/org.fmod.example D/FMOD: ms = 64
2022-06-27 10:42:25.347 678-833/org.fmod.example D/FMOD: ms = 64
2022-06-27 10:42:25.363 678-833/org.fmod.example D/FMOD: ms = 85
2022-06-27 10:42:25.380 678-833/org.fmod.example D/FMOD: ms = 107
2022-06-27 10:42:25.396 678-833/org.fmod.example D/FMOD: ms = 128
2022-06-27 10:42:25.413 678-833/org.fmod.example D/FMOD: ms = 128
2022-06-27 10:42:25.429 678-833/org.fmod.example D/FMOD: ms = 149
2022-06-27 10:42:25.446 678-833/org.fmod.example D/FMOD: ms = 171
2022-06-27 10:42:25.462 678-833/org.fmod.example D/FMOD: ms = 192
2022-06-27 10:42:25.479 678-833/org.fmod.example D/FMOD: ms = 213
2022-06-27 10:42:25.495 678-833/org.fmod.example D/FMOD: ms = 213
2022-06-27 10:42:25.512 678-833/org.fmod.example D/FMOD: ms = 235
2022-06-27 10:42:25.528 678-833/org.fmod.example D/FMOD: ms = 256
2022-06-27 10:42:25.545 678-833/org.fmod.example D/FMOD: ms = 277
2022-06-27 10:42:25.561 678-833/org.fmod.example D/FMOD: ms = 277
2022-06-27 10:42:25.578 678-833/org.fmod.example D/FMOD: ms = 299
2022-06-27 10:42:25.594 678-833/org.fmod.example D/FMOD: ms = 320
2022-06-27 10:42:25.611 678-833/org.fmod.example D/FMOD: ms = 341
2022-06-27 10:42:25.627 678-833/org.fmod.example D/FMOD: ms = 363
2022-06-27 10:42:25.644 678-833/org.fmod.example D/FMOD: ms = 363
2022-06-27 10:42:25.660 678-833/org.fmod.example D/FMOD: ms = 384
2022-06-27 10:42:25.677 678-833/org.fmod.example D/FMOD: ms = 405
2022-06-27 10:42:25.693 678-833/org.fmod.example D/FMOD: ms = 427
2022-06-27 10:42:25.710 678-833/org.fmod.example D/FMOD: ms = 427
2022-06-27 10:42:25.726 678-833/org.fmod.example D/FMOD: ms = 448
2022-06-27 10:42:25.743 678-833/org.fmod.example D/FMOD: ms = 469
2022-06-27 10:42:25.759 678-833/org.fmod.example D/FMOD: ms = 491
2022-06-27 10:42:25.776 678-833/org.fmod.example D/FMOD: ms = 491
2022-06-27 10:42:25.792 678-833/org.fmod.example D/FMOD: ms = 512
2022-06-27 10:42:25.809 678-833/org.fmod.example D/FMOD: ms = 533
2022-06-27 10:42:25.825 678-833/org.fmod.example D/FMOD: ms = 555
2022-06-27 10:42:25.842 678-833/org.fmod.example D/FMOD: ms = 576
2022-06-27 10:42:25.859 678-833/org.fmod.example D/FMOD: ms = 576
2022-06-27 10:42:25.875 678-833/org.fmod.example D/FMOD: ms = 597
2022-06-27 10:42:25.892 678-833/org.fmod.example D/FMOD: ms = 619
2022-06-27 10:42:25.909 678-833/org.fmod.example D/FMOD: ms = 640
2022-06-27 10:42:25.925 678-833/org.fmod.example D/FMOD: ms = 640
2022-06-27 10:42:25.942 678-833/org.fmod.example D/FMOD: ms = 661
2022-06-27 10:42:25.958 678-833/org.fmod.example D/FMOD: ms = 683
2022-06-27 10:42:25.974 678-833/org.fmod.example D/FMOD: ms = 704
2022-06-27 10:42:25.991 678-833/org.fmod.example D/FMOD: ms = 725
2022-06-27 10:42:26.007 678-833/org.fmod.example D/FMOD: ms = 725
2022-06-27 10:42:26.024 678-833/org.fmod.example D/FMOD: ms = 747
2022-06-27 10:42:26.040 678-833/org.fmod.example D/FMOD: ms = 768
2022-06-27 10:42:26.056 678-833/org.fmod.example D/FMOD: ms = 789
2022-06-27 10:42:26.073 678-833/org.fmod.example D/FMOD: ms = 789
2022-06-27 10:42:26.089 678-833/org.fmod.example D/FMOD: ms = 811
2022-06-27 10:42:26.106 678-833/org.fmod.example D/FMOD: ms = 832
2022-06-27 10:42:26.122 678-833/org.fmod.example D/FMOD: ms = 853
2022-06-27 10:42:26.139 678-833/org.fmod.example D/FMOD: ms = 875
2022-06-27 10:42:26.155 678-833/org.fmod.example D/FMOD: ms = 875
2022-06-27 10:42:26.172 678-833/org.fmod.example D/FMOD: ms = 896
2022-06-27 10:42:26.188 678-833/org.fmod.example D/FMOD: ms = 917
2022-06-27 10:42:26.205 678-833/org.fmod.example D/FMOD: ms = 939
2022-06-27 10:42:26.221 678-833/org.fmod.example D/FMOD: ms = 939
2022-06-27 10:42:26.238 678-833/org.fmod.example D/FMOD: ms = 956

Then, using AudioTrack you can see that the same value appears repeatedly:

2022-06-27 11:22:44.000 9086-9166/org.fmod.example D/FMOD: ms = 0
2022-06-27 11:22:44.017 9086-9166/org.fmod.example D/FMOD: ms = 0
2022-06-27 11:22:44.033 9086-9166/org.fmod.example D/FMOD: ms = 64
2022-06-27 11:22:44.049 9086-9166/org.fmod.example D/FMOD: ms = 64
2022-06-27 11:22:44.066 9086-9166/org.fmod.example D/FMOD: ms = 64
2022-06-27 11:22:44.082 9086-9166/org.fmod.example D/FMOD: ms = 64
2022-06-27 11:22:44.099 9086-9166/org.fmod.example D/FMOD: ms = 107
2022-06-27 11:22:44.115 9086-9166/org.fmod.example D/FMOD: ms = 107
2022-06-27 11:22:44.132 9086-9166/org.fmod.example D/FMOD: ms = 107
2022-06-27 11:22:44.148 9086-9166/org.fmod.example D/FMOD: ms = 171
2022-06-27 11:22:44.165 9086-9166/org.fmod.example D/FMOD: ms = 171
2022-06-27 11:22:44.181 9086-9166/org.fmod.example D/FMOD: ms = 171
2022-06-27 11:22:44.197 9086-9166/org.fmod.example D/FMOD: ms = 171
2022-06-27 11:22:44.214 9086-9166/org.fmod.example D/FMOD: ms = 235
2022-06-27 11:22:44.230 9086-9166/org.fmod.example D/FMOD: ms = 235
2022-06-27 11:22:44.247 9086-9166/org.fmod.example D/FMOD: ms = 235
2022-06-27 11:22:44.263 9086-9166/org.fmod.example D/FMOD: ms = 235
2022-06-27 11:22:44.280 9086-9166/org.fmod.example D/FMOD: ms = 299
2022-06-27 11:22:44.296 9086-9166/org.fmod.example D/FMOD: ms = 299
2022-06-27 11:22:44.313 9086-9166/org.fmod.example D/FMOD: ms = 299
2022-06-27 11:22:44.329 9086-9166/org.fmod.example D/FMOD: ms = 363
2022-06-27 11:22:44.346 9086-9166/org.fmod.example D/FMOD: ms = 363
2022-06-27 11:22:44.362 9086-9166/org.fmod.example D/FMOD: ms = 363
2022-06-27 11:22:44.379 9086-9166/org.fmod.example D/FMOD: ms = 363
2022-06-27 11:22:44.395 9086-9166/org.fmod.example D/FMOD: ms = 427
2022-06-27 11:22:44.412 9086-9166/org.fmod.example D/FMOD: ms = 427
2022-06-27 11:22:44.428 9086-9166/org.fmod.example D/FMOD: ms = 427
2022-06-27 11:22:44.445 9086-9166/org.fmod.example D/FMOD: ms = 469
2022-06-27 11:22:44.461 9086-9166/org.fmod.example D/FMOD: ms = 469
2022-06-27 11:22:44.478 9086-9166/org.fmod.example D/FMOD: ms = 469
2022-06-27 11:22:44.494 9086-9166/org.fmod.example D/FMOD: ms = 469
2022-06-27 11:22:44.511 9086-9166/org.fmod.example D/FMOD: ms = 533
2022-06-27 11:22:44.527 9086-9166/org.fmod.example D/FMOD: ms = 533
2022-06-27 11:22:44.544 9086-9166/org.fmod.example D/FMOD: ms = 533
2022-06-27 11:22:44.560 9086-9166/org.fmod.example D/FMOD: ms = 533
2022-06-27 11:22:44.577 9086-9166/org.fmod.example D/FMOD: ms = 597
2022-06-27 11:22:44.593 9086-9166/org.fmod.example D/FMOD: ms = 597
2022-06-27 11:22:44.610 9086-9166/org.fmod.example D/FMOD: ms = 597
2022-06-27 11:22:44.626 9086-9166/org.fmod.example D/FMOD: ms = 661
2022-06-27 11:22:44.643 9086-9166/org.fmod.example D/FMOD: ms = 661
2022-06-27 11:22:44.659 9086-9166/org.fmod.example D/FMOD: ms = 661
2022-06-27 11:22:44.676 9086-9166/org.fmod.example D/FMOD: ms = 661
2022-06-27 11:22:44.692 9086-9166/org.fmod.example D/FMOD: ms = 725
2022-06-27 11:22:44.708 9086-9166/org.fmod.example D/FMOD: ms = 725
2022-06-27 11:22:44.725 9086-9166/org.fmod.example D/FMOD: ms = 725
2022-06-27 11:22:44.741 9086-9166/org.fmod.example D/FMOD: ms = 725
2022-06-27 11:22:44.757 9086-9166/org.fmod.example D/FMOD: ms = 768
2022-06-27 11:22:44.774 9086-9166/org.fmod.example D/FMOD: ms = 768
2022-06-27 11:22:44.790 9086-9166/org.fmod.example D/FMOD: ms = 768
2022-06-27 11:22:44.807 9086-9166/org.fmod.example D/FMOD: ms = 832
2022-06-27 11:22:44.823 9086-9166/org.fmod.example D/FMOD: ms = 832
2022-06-27 11:22:44.840 9086-9166/org.fmod.example D/FMOD: ms = 832
2022-06-27 11:22:44.856 9086-9166/org.fmod.example D/FMOD: ms = 832
2022-06-27 11:22:44.873 9086-9166/org.fmod.example D/FMOD: ms = 896
2022-06-27 11:22:44.890 9086-9166/org.fmod.example D/FMOD: ms = 896
2022-06-27 11:22:44.906 9086-9166/org.fmod.example D/FMOD: ms = 896
2022-06-27 11:22:44.922 9086-9166/org.fmod.example D/FMOD: ms = 896
2022-06-27 11:22:44.939 9086-9166/org.fmod.example D/FMOD: ms = 956
2022-06-27 11:22:44.955 9086-9166/org.fmod.example D/FMOD: ms = 956
2022-06-27 11:22:44.972 9086-9166/org.fmod.example D/FMOD: ms = 956

Thank you for the detailed reproduction steps, I can see what you mean now. I find the results are consistent when using the default sleep time of 50- if you need more granularity then I think AAudio is the way to go.
As for the latency issue, you can try setting a smaller buffer size using System::setDSPBufferSize, I found going as low as 32 for bufferlength produced reduced latency without affecting performance. Other general things you can do to reduce latency are:

Thank you. I will try setting a smaller buffer size.

I’m sorry to reopen an old post, but almost 2 years later I still have the same problem: FMOD takes about 400ms to start with AAudio. I’d like to know if it’s possible to make it as fast as with OpenSL or AudioTrack.

The test I’ve done is as follows: using your example play_sound.cpp, I added the function

#include <chrono>

uint64_t timeSinceEpochMillisec() {
    using namespace std::chrono;
    return duration_cast<milliseconds>(system_clock::now().time_since_epoch()).count();
}

Then I calculate the time it takes for the init function:

    result = system->setOutput(FMOD_OUTPUTTYPE_AUDIOTRACK);
    ERRCHECK(result);

    uint64_t start = timeSinceEpochMillisec();

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

    uint64_t end = timeSinceEpochMillisec();

    uint64_t elapsed = end - start;

With FMOD_OUTPUTTYPE_AAUDIO it takes about 400ms. With FMOD_OUTPUTTYPE_OPENSL or FMOD_OUTPUTTYPE_AUDIOTRACK it takes about 60 ms.

Changing the buffer size does not help. Is it possible to minimize the startup time?"

We do not have any control over how long it takes to initialize an audio driver, and I am not sure why it would be a problem that FMOD_System_Init takes 200ms to initialize when using AAudio.
FMOD_System_Init should only be called once at the start of the application, and you should be initializing it well before you need to start playing a sound, not at the same time you need a sound to play.

Can you please provide more context on when you are calling FMOD_System_Init, and why you need it to start playing audio within 60ms of the FMOD_System being initialized?

Thank you for your response.

If reducing the initialization time isn’t feasible, that’s completely fine. I’ll consider relocating the FMOD_System_Init call to a different part of the process, so the delay becomes imperceptible.