Since we started using it multiple years ago, our game has had a sporadic crash in the FMOD Studio library. It doesn’t seem to happen on desktop (Win / OSX) and happens less on iOS (1%) than Android (5%). It’s not tied to a specific OS version or device type.
It usually crashes in an unassuming function in the C++ standard library. The location changed from time to time over the years. This might indicate a vtable or other function pointer address corruption.
We’ve experimented with the sync / async settings of FMOD and the Event callback function.
I did not find a solution that reduced the crash count this way.
We’ve experimented with not adding the AudioInstances to the ChannelGroup in the callback, but queueing them and adding them within the “Update” call.
This did not reduce the crash count.
We’ve experimented with adding mutexes when calling FMOD functions and when changing or accessing members of the game’s AudioManager.
Other than causing a deadlock sometime, this did not reduce the crash count.
We’ve added validity checks everywhere we could. Both the FMOD “isValid” check and this-integrity checks trough globals.
I’d really like to fix this problem because of a few reasons. First off, loads of people are using FMOD and I don’t think all of them have this crash rate. Furthermore, even if we speculate that the game is crashing because (for instance) the game is terminating, and the user is unaware, this still makes our app not qualify for App Store Featuring. I also think it should be solvable because we don’t do anything very demanding with the audio.
- Play a sample
- Loop a sample
- Stop a looping sample
- Stream over 2 music channels and crossfade
- Add playing sample to a volume group (through the callback)
- Pause / unpause via mixerSuspend / mixerResume
- Set panning, volume, pitch
I was hoping that someone here could give me more insight into what I’m doing wrong; initialization parameters? Threading faux-pas? Please help…
More details: