# Lag when calling FMOD\_System\_Init in 2.02.07 (vs 1.10.20)
**URL:** https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883
**Category:** FMOD Engine
**Tags:** android
**Created:** [June 13, 2022, 7:30am UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883 "2022-06-13T07:30:09Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@sviudes](https://qa.fmod.com/u/sviudes)
#### Post date: [June 13, 2022, 7:30am UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883/1 "2022-06-13T07:30:09Z")
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
---
### Author:  [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)
#### Post date: [June 21, 2022, 4:50am UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883/2 "2022-06-21T04:50:41Z")
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?
---
### Author:  [@sviudes](https://qa.fmod.com/u/sviudes)
#### Post date: [June 27, 2022, 9:31am UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883/3 "2022-06-27T09:31:23Z")
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:
```auto
if (playing) {
__android_log_print(ANDROID_LOG_DEBUG, "FMOD", "ms = %d", ms);
}
```
In order to get `__android_log_print working` I also added `#include `. 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
---
### Author:  [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)
#### Post date: [July 6, 2022, 5:30am UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883/4 "2022-07-06T05:30:40Z")
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`](https://fmod.com/docs/2.02/api/core-api-system.html#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:
- Pre-loading all of your sounds with [`System::createSound`](https://fmod.com/docs/2.02/api/core-api-system.html#system_createsound) rather than creating them as needed.
- Export your audio files in mp3 format and load them into the FMOD API using the [`FMOD_CREATECOMPRESSEDSAMPLE`](https://fmod.com/docs/2.02/api/core-api-common.html#fmod_createcompressedsample) flag.
- Avoid loading sounds using [`FMOD_CREATESTREAM`](https://fmod.com/docs/2.02/api/core-api-common.html#fmod_createstream).
---
### Author:  [@sviudes](https://qa.fmod.com/u/sviudes)
#### Post date: [July 19, 2022, 5:07pm UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883/5 "2022-07-19T17:07:46Z")
> [@sviudes](#):
>
> FMOD\_System\_Init
Thank you. I will try setting a smaller buffer size.
---
### Author:  [@sviudes](https://qa.fmod.com/u/sviudes)
#### Post date: [April 12, 2024, 2:29pm UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883/6 "2024-04-12T14:29:55Z")
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
```auto
#include
uint64_t timeSinceEpochMillisec() {
using namespace std::chrono;
return duration_cast(system_clock::now().time_since_epoch()).count();
}
```
Then I calculate the time it takes for the init function:
```auto
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?"
---
### Author:  [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)
#### Post date: [April 15, 2024, 12:21am UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883/7 "2024-04-15T00:21:06Z")
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?
---
### Author:  [@sviudes](https://qa.fmod.com/u/sviudes)
#### Post date: [April 17, 2024, 2:43pm UTC](https://qa.fmod.com/t/lag-when-calling-fmod-system-init-in-2-02-07-vs-1-10-20/18883/8 "2024-04-17T14:43:38Z")
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.