Re: AURemoteIO::Initialize failed: -12985 on iOS 5
Re: AURemoteIO::Initialize failed: -12985 on iOS 5
- Subject: Re: AURemoteIO::Initialize failed: -12985 on iOS 5
- From: Paul Scott <email@hidden>
- Date: Sun, 08 Jan 2012 16:29:59 -0800
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
that your audio session has automatically been reactivated.
I read the doc about AudioSessionSetActive(true) being required for case kAudioSessionEndInterruption, but it doesn't seem to be related to this problem. All possible combinations of AudioSessionSetActive() in both cases of the interruption listener, or in the main loop via scheduled timer from the interruption listener, have not solved the problem, but some combinations can certainly make things worse!
In addition to a solution -- I expect there is one -- I'd also like to see a formal description of the -12985 error.
Thanks,
Paul |
_______________________________________________
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