Correct flow for handing mixerResume() failures

This question partially continues from my previous one at [iOS] change to setDSPBufferSize causing increased occurrence of 'Error initializing output device.' where I experienced failures to initialize FMOD at startup on iOS.
I previously fixed this by, as recommended, sleeping and retrying to initialize the FMOD system once more which seemed to resolve my problem.

I am however experiencing the same issue when calling mixerResume() after the application returning to the foreground.

My question is: What are the correct steps to take in the case of mixerResume() failing? and how does FMOD handle this.

I found reference in [iOS] Frequent SystemNotInitializedException saying that the initialization will throw an ‘exception’ once and switch to no sound mode afterwards. Does this still apply to current FMOD? If so, is it safe to accept the single error of Error initializing output device. and to continue to make calls to FMOD as if resuming was successful?

I am uncertain that it is safe to perform a sleep in resuming the app from background and therefore hope to opt for a ‘graceful failure’ in having FMOD continue to run but not throw errors for all calls. (no sound is acceptable) instead of the current crashing that we are experiencing on trying to resume the mixer.


I would not expect to see mixerResume() fail due to an initialization error, the system has already been initialized and should be in a suspended state due to being sent to the background. mixerResume() will return an FMOD_RESULT that should provide more information on the ‘failure’.

Trying to call into FMOD while it is still in the background would result in a failure as it is not allowed to run in the background.

Sure, I presume the issue might be happening due to the app still being ‘backgrounded’ and an system timing issue with didResumeActive/ audiosession.

We can’t reproduce the issue locally so can’t really get the FMOD_RESULT back easily, hence this question was more on how to handle the failure in resuming (such as trying to call resume in the background).

We don’t really have a “correct flow” for handling a mixerResume failure, we recommend using system callbacks to call mixerSuspend/Resume so that it gets called at the right time.

I see, thanks. We were actually currently calling mixerResume() as a callback from applicationDidBecomeActive but have switched it to as described by the link (AVAudioSessionInterruptionNotification) hopefully this may resolve the issues.

We’ve also added logging to see the issues with resuming mixer in the future if it reoccurs.