Apple

On Wed, May 29, 2013 at 7:42 AM, Beinan Li <email@hidden> wrote:

Thanks Kevin.

About the AVAudioSession interruption part, I thought adding a listener function in AudioSessionInitialize() call does the same thing as adding a delegate that handles begin/endInterruption:. We added this listener in our C++ CoreAudio client code. However, that callback seems to only respond to interruptions such as incoming phone calls and alarms, but is not called when we do remote controls.

About your remote control part, if I understand you correctly, it's a Cocoa thing and there is no way to handle it inside our CoreAudio C++ code, right? I don't see our app icon in the media control bar you described there. I guess that would be where the problem is because doing media control with the double-click home button=>swipe left gives us the exact same problem.

Thanks,
Beinan
On Tue, May 28, 2013 at 9:37 PM, Kevin Dixon <email@hidden> wrote:
The routes represent the "physical" path the audio takes after it leaves your application. It probably has nothing to do with your problem at hand.

You should have a delegate attached to the AVAudioSession. Add a delegate which implements -(void)beginInterruption and -(void)endInterruptionWithFlags:(NSUInteger)flags

Furthermore, the "focus" for the remote control API is determined by several things.

1. you must called [[UIApplication sharedApplication] beginReceiginvRemoteControlEvents]

2. you must override your application's -(BOOL)canBecomeFirstResponder method
3. call [self becomeFirstResponder]

you will then get called on -(void)removeControlReceivedWithEvent:(UIEvent*)event

you can see if your app is receiving remote control events if you double-click the home button, then swipe left to see the media controls. If your app icon is there, you are receiving the events.

Hope that helps

-Kevin
On Tue, May 28, 2013 at 8:27 AM, Beinan Li <email@hidden> wrote:
I further checked the doc about Audio Routes.

It looks like they are in charge of routing to I/O hardware instead of software (apps). For example, output routes include:
const CFStringRef kAudioSessionOutputRoute_LineOut;
const CFStringRef kAudioSessionOutputRoute_Headphones;
const CFStringRef kAudioSessionOutputRoute_BluetoothHFP;
const CFStringRef kAudioSessionOutputRoute_BluetoothA2DP;
const CFStringRef kAudioSessionOutputRoute_BuiltInReceiver;
const CFStringRef kAudioSessionOutputRoute_BuiltInSpeaker;
const CFStringRef kAudioSessionOutputRoute_USBAudio;
const CFStringRef kAudioSessionOutputRoute_HDMI;
const CFStringRef kAudioSessionOutputRoute_AirPlay;
In my scenario, I "imagine" that a possible route change would be audio stream was routed to Music app or my own app. So I fail to see how the routes listed above can account for my scenario.

Beinan
On Tue, May 28, 2013 at 11:02 AM, Beinan Li <email@hidden> wrote:

Hello Valentin,

I tried to use this property and gave it a listener callback. Unfortunately, in my scenario, my callback wasn't called. I tried to set that property after AudioSessionInitialize(NULL, NULL, interruptListener, myObj), then before or after the AudioSessionSetActive(true) call. Didn't make any difference.

Am I calling it in the wrong way or order or is it simply saying that my audio route hasn't changed when I pause/resume the background Music playback?

Thanks,
Beinan

On Mon, May 27, 2013 at 1:21 PM, Valentin Radu <email@hidden> wrote:

Hi Beinan,

Not sure if I get your question right, but if I do, there is

AudioSessionAddPropertyListener (kAudioSessionProperty_AudioRouteChange,

yourCallback, (__bridge void *)(objectThatCanBeReferencedFromCallback));

that allows you to listen for audio route changes, like the one you described.

Cheers,
Valentin

On 27 May 2013, at 19:13, Beinan Li <email@hidden> wrote:

Hi CoreAudio,

Our iOS app uses AudioSessionCategory_SoloAmbientSound.

And if we follow this procedure, the audio of our app will become silence:
1. Turn on the built-in Music app and play it.
2. Turn on our app and make the app sounds play and observe that the Music app is silenced (as expected).

3. Resume the music app playback using the playback control on the bundled iPhone earplug. Notice that app sounds stopped (as expected).
4. Pause the music app playback using the earplug control.

Now we notice that our app is silent. Audio doesn't come back as "expected".

I initially suspected that maybe the audio session was hijacked by the Music app. So I tried to reset active session in several delegates applicationWillResignActive and applicationDidBecomeActive. But that didn't work.

Is there a way (e.g., a delegate) to track this kind of interruptions?

Thansk!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)

This email sent to email@hidden

Valentin Radu
cocoaexposed.com
@CocoaExposed

_______________________________________________
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