FMOD file thread not paused on app pause - Android

Hi, we are using FMOD with Unity and noticed that there is an FMOD file thread that isn’t getting paused when the app pauses. All the other threads get paused or maybe even destroyed. Here is a snapshot from Streamline (Arm Mobile studio profiler).

I thought it happens when we have streaming music, but you see it even when there is no music playing.

Is this a bug, or maybe something wrong on our side?



Suspending the FMOD mixer on Android should pause all threads - do you have Unity built-in audio disabled? Since Unity’s audio system is based on a old version of FMOD, if Unity audio is still enabled you may be seeing the Unity-native FMOD thread.

No. We turned off Unity audio.

This is called from FMOD Studio Unity integration in FMODUnity.RuntimeManager (I assume this should be enough to suspend everything):

void OnApplicationPause(bool pauseStatus)
            if (studioSystem.isValid())

                if (pauseStatus)

But the file thread doesn’t seem to stop (just everything else). I tested on release native FMOD libs.

Thanks for confirming that Unity audio is disabled on your end.

I’ve been able to reproduce it and can confirm that it’s a bug on our end. The FMOD file thread isn’t owned by the FMOD.System object that the integration creates, and as such doesn’t participate in the normal thread-locking system that we use on Android. Thanks for reporting the issue - I’ve passed it along to the development team for further investigation.

Hi, is there any plan already when this will be fixed? Thanks!

The file thread issue hasn’t been scheduled yet, but we’ll try to get it fixed in a future release. That said, I’ve noted your interest internally.

Just to follow up on this issue, we have scheduled it but work hasn’t commenced as yet.

To give some background, all native threads on Android like to keep running even when the app transitions into the background. On some devices, manufacturer software or platform software suspends the app completely and this issue goes away. For devices that don’t do this, we introduced System::mixerSuspend and System::mixerResume. Those functions intentionally lock all the internal threads to stop them from spinning, however, the file thread (which works differently) didn’t get this behavior. Since all other threads are stopped, the file thread won’t be given more work to do. The file thread operates on a sleep timer, it wakes up, sees it has no tasks to do, then goes back to sleep.

Essentially the thread will be doing nothing, but waking up and sleeping a thread is not without a small power cost. So we do want to fix this, but perhaps the situation isn’t as bad as it may have seemed.