FMOD fails to initialize on iOS after shutting down then quickly restarting app

FMOD Studio
1

On iOS, we’re running into a failure for FMOD to initialize…the code is roughly this:

FMOD::Studio::System::create(&mSystem);
mSystem->getLowLevelSystem(&mLowLevelSystem);
mLowLevelSystem->setFileSystem(...);
mLowLevelSystem->setSoftwareFormat(gSampleRate, FMOD_SPEAKERMODE_STEREO, 0);
mLowLevelSystem->setDSPBufferSize(kAudioDSPBufferSize, 4);
mSystem->initialize(kMaxAudioChannels, FMOD_STUDIO_INIT_NORMAL, FMOD_INIT_NORMAL | FMOD_INIT_3D_RIGHTHANDED, NULL);

Sometimes, when the app is force-closed then quickly restarted the “mSystem-initialize” call will fail.

I’ve tracked it down to this, using the fmod logging libraries…

ERROR: [Main] >aurioc> 807: failed: ‘!pla’ (enable 2, outf< 1 ch, 44100 Hz, Int16> inf< 2 ch, 0 Hz, Float32, non-inter>)

fmod_output_coreaudio.cpp, line 215, OutputCoreAudio::init: Cannot initialize audio device. (err: 561015905)

that error code maps to AVAudioSessionErrorCodeCannotStartPlaying

This is on FMOD 1.05.13 - as a test I used the latest FMOD (1.08.xx) and I was still able to repro this bug.

I also tried a loop approach, basically if we fail to init then tear down everything, sleep 1 second, try again…but that didn’t help.

Any ideas?

Thanks!

2

Are you able to reproduce this in our examples?

Can you verify your AudioSession API calls are all succeeding?

3

The only audio session API we make succeeds… it’s this:

bool success = [[AVAudioSession sharedInstance]
setCategory:AVAudioSessionCategoryAmbient
error: &setCategoryError];

We do call this before trying to initialize FMOD.

Only thing that might smell here to me is the ambient session category: looking at FMOD docs it seems like FMOD might try to use the solo ambient category, but here we set to ambient.

Will FMOD try and alter the session category under the covers?

4

FMOD 5 will not touch the audio session API (unlike FMOD 4). With FMOD 5 it is up to you to configure an activate it. Make sure you call setActive also:

success = [session setActive:TRUE error:nil];
assert(success);

Also, can you verify that this issue happens in our examples?

5

I think I found a fix. Once I ensured we had the audio sesstion setActive call, I was able to catch that it was also failing.

In another FMOD forum post someone on the FMOD team mentioned: “We had some troubles a while back with certain devices reporting init errors because the internal audio state was in flux. Generally closing the FMOD system and try again was sufficient to recover.”

So, I took that 1 level lower, and would retry (after a small sleep) the setActive call, and it works.

6

I’m glad you were able to work around the issue, the comment was likely from me. I’ve certainly seen cases where the phone has transitioned to the foreground but as far as the audio system is concerned it is still backgrounded causing the AudioSession errors.