Re: iPod Touch, headset and kAudioSessionBeginInterruption
Re: iPod Touch, headset and kAudioSessionBeginInterruption
- Subject: Re: iPod Touch, headset and kAudioSessionBeginInterruption
- From: Tom Lieber <email@hidden>
- Date: Thu, 19 Aug 2010 21:59:38 -0700
On Thu, Aug 19, 2010 at 4:59 PM, Sam Clegg <email@hidden> wrote:
> This is my first post the list so please go easy on me. I'm
> resurrecting thread from back in March of last year:
>
> http://lists.apple.com/archives/coreaudio-api/2009/Mar/msg00341.html
>
> Did this ever get resolved? If so please ignore the rest of this
> message.
>
> We've been experiencing this exact same problem and can reproduce it
> pretty consistently on iTouch devices. The problem is essentially that
> removing the headset while while in PlayAndRecord mode causes an
> AudioSession interruption that never ends.
>
> Reproduction steps:
>
> 1) Download the SpeakHere example from the apple developer site.
> 2) Put printf statements in the route changed callback, the
> interruption callback and the input availability callback.
> 3) Run the app on an iPod touch with the headset initially plugged
> 4) Start recording and unplug the headset during recording.
> 5) Notice the following sequence of printf statements in the
> debug console:
>
> - route changed (stopping input queue)
> - interruptionListener: Begin
> - input availability changed
>
> Notice the lack of any end to the interruption.
>
> In our more complicated application I've tried doing all kind of things
> to the audio session when the initial route changed callback is fired,
> but whatever I do I can't seem to avoid the following interruption.
>
> I myself have reproduced that above problem on an iTouch 3G running iOS
> 4.1 beta3.
I was eventually able to create a RemoteIO app that would withstand
headset abuse on the Touch. The key points were:
- When calling AudioSessionSetActive after a route change, you
sometimes have to call it more than once for it to succeed.
- When you set the audio category, use PlayAndRecord only when input
is available (kAudioSessionProperty_AudioInputAvailable). Otherwise,
use MediaPlayback and you'll just get zeroes for input.
- Do not call AudioOutputUnitStop at the start of an interruption. The
interruption is your notification that you _have_ been stopped, so
this extra AudioOutputUnitStop (as appears in the aurioTouch example)
does nothing except stop the audio unit during the fake interruption
when it doesn't need to.
By "fake" interruption I mean the seemingly endless interruption you
mentioned. According to Core Audio people I've heard from, the
"endless" interruption doesn't signify that your audio has been
interrupted and to wait for the end interruption event (like most
audio interruptions); on the Touch sometimes the interruption is just
to let you know that there was an interruption which was handled
automatically (and has no corresponding end interruption). I guess the
intermittent headset unplug problem, which I've also suffered greatly
from, is one of those cases.
In summary, the interruption interruption interrupt begin interrupt
interruption end interrupt interrupt interruption.
--
Tom Lieber
http://AllTom.com/
http://favmusic.net/
_______________________________________________
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