# Do FMOD function calls block FMOD system threads? **URL:** \ **Category:** FMOD Engine\ **Tags:** android, cpp\ **Created:** [August 26, 2021, 9:12pm UTC](https://qa.fmod.com/t/do-fmod-function-calls-block-fmod-system-threads/17612 "2021-08-26T21:12:44Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![jiyongman](https://avatars.discourse-cdn.com/v4/letter/j/ebca7d/32.png) [@jiyongman](https://qa.fmod.com/u/jiyongman)\ **Post date:** [August 26, 2021, 9:12pm UTC](https://qa.fmod.com/t/do-fmod-function-calls-block-fmod-system-threads/17612/1 "2021-08-26T21:12:44Z")
AFAIK, older FMOD Ex wasn’t thread-safe. It’s very nice that we don’t have to think too much about thread-safe design with FMOD Studio anymore. But I wonder if too many FMOD function calls in very a short time will disturb FMOD system threads (due to locks). I mean, I have a worker thread that keeps calling **FMOD\_System\_Update()** in a loop. That thread also calls many other FMOD functions. Firstly, it traces every sound object created by the main thread by calling **FMOD\_Channel\_IsPlaying()**. If it returns false, the object will be removed after **FMOD\_Channel\_RemoveDSP()** is called. Otherwise, **FMOD\_Channel\_SetVolume()** may be called to simulate _fade-out_, or **FMOD\_Channel\_Stop()** may be called if there’s a _stop_ request from the main thread. And the main thread calls **FMOD\_System\_PlaySound()** when there’s input from a user, MIDI file, etc. I simplified things here, so there are actually more FMOD function calls in both threads. Because too many sound objects can be created by the main thread and the worker thread keeps running with almost zero sleep time (for responsiveness), I think FMOD threads may be impacted. Should I add a little longer sleep time to the worker thread? (The worker thread’s priority is lower than FMOD’s.) ---
**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\ **Post date:** [August 31, 2021, 2:52am UTC](https://qa.fmod.com/t/do-fmod-function-calls-block-fmod-system-threads/17612/2 "2021-08-31T02:52:14Z")
Interesting question- the default behaviour of the Core API is that, where possible, commands that cannot be executed in any given call to `FMOD_System_Update()` are moved to the next call. Perhaps there is an upper limit to how many of these calls you can make before they start getting dropped or you run out of memory, but I think that situation would be an edge case. General usability rule for system responsiveness is that 100ms is pereceived as instantaneous, so I do not think you need a close-to-zero sleep time between calls to `FMOD_System_Update()`. We use 50ms in the API examples and that is a sensible minimum. ---
**Author:** ![jiyongman](https://avatars.discourse-cdn.com/v4/letter/j/ebca7d/32.png) [@jiyongman](https://qa.fmod.com/u/jiyongman)\ **Post date:** [August 31, 2021, 11:43am UTC](https://qa.fmod.com/t/do-fmod-function-calls-block-fmod-system-threads/17612/3 "2021-08-31T11:43:03Z")
I didn’t know that Core API works that way. Thank you! But still, even to check the upper limit, I think Core API needs either lock or atomic/volatile variables, and that means too many FMOD function calls from different threads may be harmful. So my guess is that only the **FMOD\_System\_Update()** function call interrupts feeder or/and mixer threads. Other FMOD function calls only interrupt the thread where those are called and **FMOD\_System\_Update()** is called. Am I correct? I’ll take the general usability rule, but I’m asking this just to better understand the FMOD system. ---
**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\ **Post date:** [August 31, 2021, 11:30pm UTC](https://qa.fmod.com/t/do-fmod-function-calls-block-fmod-system-threads/17612/4 "2021-08-31T23:30:19Z")
Yes, Core API has mutexes around the public API functions, so at the upper limit of API calls, the thread you are calling the API from will be unresponsive, but that won’t affect audio output- something blocking the mixer thread on the other hand is where you start getting problems with buffer starvation, with intermittent silence and glitching. `FMOD_System_Update()` does not interrupt the mixer thread, it just commits changes to parameters, 3d positions and things like that. ---
**Author:** ![jiyongman](https://avatars.discourse-cdn.com/v4/letter/j/ebca7d/32.png) [@jiyongman](https://qa.fmod.com/u/jiyongman)\ **Post date:** [September 1, 2021, 9:10am UTC](https://qa.fmod.com/t/do-fmod-function-calls-block-fmod-system-threads/17612/5 "2021-09-01T09:10:09Z")
Thank you! ---
**Author:** ![jiyongman](https://avatars.discourse-cdn.com/v4/letter/j/ebca7d/32.png) [@jiyongman](https://qa.fmod.com/u/jiyongman)\ **Post date:** [September 1, 2021, 12:57pm UTC](https://qa.fmod.com/t/do-fmod-function-calls-block-fmod-system-threads/17612/6 "2021-09-01T12:57:15Z")
Oh, one last question! I’m calling **FMOD\_System\_Init()** with the **FMOD\_INIT\_STREAM\_FROM\_UPDATE** flag not to create the stream thread. That means updating the stream engine can be done only by **FMOD\_System\_Update()**. So I wonder if calling the function every 100ms (as you said) would be enough for streaming any file type too. ---
**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\ **Post date:** [September 2, 2021, 12:28am UTC](https://qa.fmod.com/t/do-fmod-function-calls-block-fmod-system-threads/17612/7 "2021-09-02T00:28:31Z")
Interesting point, as a test I ran one of our API example with the setup you’ve described- the 100ms sleep works fine, but setting from about 200ms onwards results in the mixer thread looping the existing buffer repeatedly until the next call to `FMOD_System_Update()`, which repopulates the buffer and starts looping that, so on and so fourth until the stream finishes. So this would mean that slow and blocking operations would create glitches in the audio as it continues recylcing the old buffer. Perhaps if you wanted to run it in the **FMOD\_INIT\_STREAM\_FROM\_UPDATE** mode you should set it to a lower value.