0
0

I’ve come across a situation on iPhone where if you call FMOD_IPhone_OtherAudioIsPlaying from applicationDidBecomeActive after holding the home button to enable Siri and then pressing the home button again while Siri is waiting for you to talk, this function call returns true. Is this the desired behavior? Because of this, the music in my game doesn’t come back on after you enable Siri and exit it quickly.

Seems like the only solution is to wait a second or two to re-enable the music, unless there is a way for the library to detect this situation and return false. Unfortunately Apple doesn’t give the app delegate any info on applicationDidBecomeActive as to wether or not it’s becoming active after using Siri, so if I implement a wait before re-enabling the music, it will happen in all situations, which is not really desirable.

Has anyone else had this happen? If this is genuinely a bug, when can we expect a fix?

  • You must to post comments
0
0

That function is simply a wrapper for AudioSessionGetProperty with kAudioSessionProperty_OtherAudioIsPlaying. As to whether that API should return true for when Siri is activate is probably a question for Apple, if it’s persisting after Siri is closed then it sounds like a bug. This doesn’t sound like something we can do anything about from FMOD unfortunately.

  • You must to post comments
0
0

Ok. Yes it appears that for some time period between the time when you press the home button while Siri is activated and the time your app is resumed, it returns true. It doesn’t persist though. From my debug output, I’m seeing that for 13 frames after we resume after using siri, that call is returning true. Do you suggest we delay our use of that call for about half a second?

  • You must to post comments
0
0

That sounds like a reasonable workaround for this issue yes.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.