FYI, I started looking at this bug. It looks like it is an iOS 5 bug with the way an app backgrounds via the notification center. iOS seems to generate a resign callback, then an active callback, and then another resign callback followed by a background callback. This resign/active/resign pattern causes us to suspend the audio engine, restore it, and then suspend it again. The problem seems to be that trying to restore audio while the app is actually trying to background leads to even more catastrophic bugs in Apple’s Core Audio backend which brings down audio in the app completely.
So the first Apple bug is the unnecessary active/resign pair of callbacks.
This leads us into the second bug of trying to restore audio when Core Audio is probably trying to shut things down which breaks Core Audio completely for the app.
Trying not to break any NDAs, I will say my brief encounter with iOS 6 betas has been promising. I would be interested in hearing any bad results on iOS 6 beta.
Addendum: We are still trying to figure out how to workaround this. It looks like iOS 4.3 has this problem too. Unfortunately, Apple changed the event callback sequence/system between 4 and 5 so the initial workaround idea we started thinking about in 5 won’t work with 4.
[import]uid: 7563 topic_id: 27447 reply_id: 117946[/import]