iOS Call interruptions on the iPhone

[Craigy]

Hi - so our first app is almost ready to go. Behaves great in the simulator - but we have come across a really odd bug on the iphone.

On a start interrupt event we dispose the audio queue and close the audio file. On interrupt end we open the audio file, create a queue, prime the buffers and start the queue. It works doing it without the interrupt but with the interrupt it doesn't play.

So basically - if the user answers the call the app restarts fine and picks up from where they left off. However, if they reject the call, the caller hangs up before answers or the call is ignored the audio doesn't play etc.

Interestingly - if we call the interruption start and end handler functions from a background thread it resumes fine.

Is anyone aware of other things we should be aware of in the difference the way the SDK / iPhone handles answered call and rejected call interruptions?

Thanks
Craig

 

[firewood]

Are you using audio session callback handlers as illustrated in the SpeakHere example? If not, audio queues won't work.

 

[Craigy]

Are you using audio session callback handlers as illustrated in the SpeakHere example? If not, audio queues won't work.

yes we are using the audio session callbacks

 

[firewood]

I wonder if your main thread could be too busy to handle the audio session callbacks promptly enough? If you don't handle them quickly enough, the OS appears to permanently kill the app's audio session in order to let the phone call or ring tone come through.

You also have to handle the callback to set your audio session as active again after a phone call is rejected, but probably not so immediately.


.

 

[pghendry]

Thanks for the suggestion firewood. Any way I can test if this is the case?

My assumption is that the audio queue will be running on a background thread and so our main thread isn't actually doing anything at the time of the interruption other than updating the positional slider and time label values. It only does that every second based on a timer thread.

One thing is that each second I call into the main thread which calculates the current audio time (by calling into the AudioQueue), creates the label text and assigns to the labels, and updates the slider. Instead I could try moving everything except the setText on the labels and setValue on the slider out of the main thread into the timer thread.

I would expect the time to create the label text and get the audio position to be in the order of a few msec or less so it seems unlikely this would keep the main thread busy. It would also seem likely that if this were the case then sometimes it would happen and other times it would work depending on timing.

I had another look at the speakhere sample and it pauses/resumes the queue. That was the approach I originally used which had the same symptoms and why I changed to disposing the audio queue and closing the file. I have switched back to pause/resume with the same problem occurring. Again it works if I call the interruption methods from a background thread.

(I'm working with Craigy BTW)

 

[priyank.ranka]

hi,

I am developing an application but i stuck with how to resume the application on the same point where user was before interrupt occurred. Its resume when user ignores the call but the application exit when user answer the call. I want user to be at the same point where it was after user answer the call. If any one has suggestion or some sample code to achieve this it will be of great help to me. Thanks a lot to look into my concern.