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).
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.
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.
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.