The rule as I understand it is that you don't get to make your session active from the background unless you are mixable and/or the "now playing" app.
On Jan 8, 2012, at 16:29 , Paul Scott wrote: On Jan 8, 2012, at 4:07 PM, < email@hidden> wrote:
I think that this has been determined to
be “works as intended”.
If so, it's definitely not "intended" for built-in iPod app, which doesn't have this problem. What is different? What arcane incantation does Apple use? When you get an interruption-ended
callback, your application might still be sufficiently backgrounded that it
doesn’t have permission to restart audio playback. You just need to wait
a little while and try again.
I have already tried -- but forgot to mention -- a scheduled timer to run the after 250ms, with exactly the same result. There are two things to watch here though: 1) On some 4.x versions of iOS, AudioOutputUnitStart failing in this
way resulted in the RemoteIO device getting borked every so often (it would “start”
but never call the render callback). Doing a complete teardown/startup of the
audio unit was required to get things working properly. I haven’t done
enough testing of iOS 5 to see if it’s an issue there though.
My complete teardown/startup makes no difference.
2) Related to the above – if you destroy a RemoteIO unit then
try to create it again straight away, you can run in to the same “starts
but never calls the callback” issue. The threshold appears to be
somewhere in the 10-20 millisecond range, but an order of magnitude safety
margin is probably a good idea (and usually not an issue).
Again, even after 250ms the problem persists.
Also, you don’t want to do AudioSessionSetActive(FALSE)
when getting interrupted. This can make some things unhappy IIRC. The AudioSessionSetActive(TRUE)
at the end of an interruption is I think required – there is no guarantee
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|