Hi, I’m using version 2.00.08. I have two questions:
Can I do fmod system initialization on iOS before I do [[AVAudioSession sharedInstance] setActive:true] first time? Will it fail in such way of initialization If I do setActive call later?
Which calls are safe between mixerSuspend() and mixerResume() calls on iOS/Android? There is information in android part of documentation that tells: “It is extremely important to ensure no FMOD APIs are called in-between suspend and resume as they run the risk of causing a deadlock.”. But there is no such information in iOS part of documentation. Also I’ve found this forum thread where you say: “MixerSuspend maintains the internal state by keeping everything alive in memory, any calls made to FMOD during this time will be added to the queue and be processed once MixerResume is called”. As I understand all calls to FMOD API are safe, aren’t they?
If you don’t activate your audio session your application will use the default audio session (you can read more here).
For Android, you must not call any FMOD APIs between mixerSuspend and mixerResume, otherwise you risk deadlocking your application. For iOS the warning is less severe, you may call FMOD APIs but it’s recommended you don’t, any Studio API commands issued will be queued, if this keeps happening the queue will expand and expand.
Thank you for your response. One more thing about first question: is it ok if I try to initialize FMOD when application is inside interruption state? I can not activate session in that time and default session is in inactive state. Is FMOD sensitive to iOS session state at all?
You won’t be able to initialize FMOD if there is currently an interruption, the phone will have excusive access to the sound device. When you call mixerSuspend, internally we release the audio interface allowing the phone to use it, then mixerResume reacquires it resuming playback.
Are you experiencing a particular issue or are these questions hypothetical?
I have particular issue. If you start application and call Siri a moment later then you won’t be able to activate session until Siri is active. But all others parts of application will work at the background and will do calls to audio system that is not initialized (I can not influence other parts of app). As I understand I need to make my inner queue of audio calls and put it into fmod only after session activation/FMOD initialization, but it’s not very comfortable. Can FMOD handle such situation?
Also I want to admit that all this thing with restriction of FMOD call between mixerSuspend/mixerResume is uncomfortable because developer should do inner abstraction of audio calls to handle this period of time.
The mixerSuspend / mixerResume system was built with the assumption the application would be paused in-between those points. What you describe where the application continues running, perhaps for some time sounds similar to the situation on Windows where you unplug your last sound device and are left with none.
For that case we encourage developers to call setOutput(FMOD_OUTPUTTYPE_NOSOUND), which allows all FMOD APIs to continue working without using any audio device. Would something like this work for you?
Currently on iOS you cannot call setOutput after initialization, however we should be able to make that work in a patch. Please share your thoughts.
Should I replace calls of mixerSuspend/mixerResume with calls setOutput FMOD_OUTPUTTYPE_NOSOUND/FMOD_OUTPUTTYPE_AUTODETECT? Or may be I should add these calls additionaly to mixer calls? Or how should I use it?
Do you have any ideas how to handle FMOD initialization in the situation when Siri takes audio session at the start of application? Can I call FMOD initialization in that period of time (may be with setOutput to NOSOUND) or should I wait until Siri finishes work and application gets audio session?
The idea is you would set FMOD to no-sound if you find yourself initializing in the background and then switch to core-audio when SIRI is done. However for iOS FMOD doesn’t support switching output while running (we would need to add this).
I can’t offer any guarantees but I’ve scheduled the task for our 2.00.11 release, ~1 month away.
It cannot go into 2.00.10 because that is in QA at the moment.
I have expirienced another bug with mixer suspend/resume on iOS. Actions on app going to background are:
Set master channel group zero volume.
Set master channel group on pause.
Mixer suspend.
When app going to foreground I do:
Mixer resume
Set master channel group pause off.
Bu there is short sound when app have appeared from the background. If I remove mixer operations there isn’t such short sound. Iexperimented with flushCommands but had no effect. On Android and windows it works as expected without short sound.