Using kAudioSessionProperty_OtherMixableAudioShouldDuck on iPhone

Question

I am trying to get consistent behavior from the kAudioSessionProperty_OtherMixableAudioShouldDuck property on the iPhone to allow mixing iPod music, and I'm having problems. At the beginning of my application, I set the Ambient category as follows:

-(void) initialize { [[AVAudioSession sharedInstance] setCategory: AVAudioSessionCategoryAmbient error: nil]; } 

Later, when I try to play audio, I set the duck property using the following method:

 //this will crossfade the audio with the ipod music - (void) toggleCrossfadeOn:(UInt32)onOff { //crossfade the ipod music AudioSessionSetProperty(kAudioSessionProperty_OtherMixableAudioShouldDuck,sizeof(onOff),&onOff); AudioSessionSetActive(onOff); } 

I call it passing the numeric "1" just before playing the sound as follows:

  [self toggleCrossfadeOn:1]; [player play]; 

Then I call the crossfade method, passing zero when my application's sound terminates using playback, so that stops the callback:

 -(void) playbackIsStoppingForPlayer:(MQAudioPlayer*)audioPlayer { NSLog(@"Releasing player"); [audioPlayer release]; [self toggleCrossfadeOn:0]; } 

In my production application, this exact code works as expected, causing the iPod to fade out before playing the application’s sound, and then disappear when the sound ends. In the new project that I recently started, I have a different behavior. IPod sound fades and never fades. In my working application, I use AVAudioPlayer, where in my new application I wrote a custom audio player that uses audio queues. Can someone help me figure out the differences and the proper use of this API?

Answer 1

I just found part of the problem. It seems that this is due to the timing. I believe that my user player still powers the audio system when I make a call to add sound back. If I set a breakpoint in the IsStoppingForPlayer playback method, then it works as expected, since the breakpoint stops execution long enough for the remaining audio to end its way through the audio queues.

Answer 2

In one of our applications, we call AudioSessionSetActive(YES) , and then immediately call AudioSessionSetActive(NO) when we want to remove ducking to get around this problem.