1

I need a way to change or disable the AudioSessionInterruptionListener after the AudioSession has been initialized.

Here's why: In some use cases my app must run in the background with audio recording, so the audio background mode is set - this works. When a call or other interrupt happens I have to inform some other objects to cleanly stop the recording - this works. Then when the app is done with the AudioSession I call AudioSessionSetActive(false); - this works (if the app is sent to the background with the session active, I get the red bar at the top, if the session is inactive, the red bar does not appear. Although, I guess, technically the app is still in "active" background mode).

However! In the case that I'm done with recording, and the app has been sent to the background and the audio session has already been deactivated, if a call comes in, or if Siri is activated, then my app still receives the AudioSessionInterruptionListener callback. Yes, I can add code to test if my app should currently be responding to interrupts. However, I see this as a bug. If I've deactivated the AudioSession, the interrupts should stop being called, in fact all audio session/property listeners should stop being called.

How can I change or disable the AudioSessionInterruptionListener? Or maybe another way to ask this, how can I prevent my app from "using" the background mode when it doesn't need it?

Additional Information

Okay, it seems that in iOS 6 there are now NSNotifications for AudioSession interrupts: AVAudioSessionDidBeginInterruptionNotification and AVAudioSessionDidEndInterruptionNotification. However, I'm supporting iOS 5.1 and above so this doesn't help. And the same documentation where I found the new notifications says that the delegate property for the Obj-C interface AVAudioSession is depreciated (in IOS 6), so I probably shouldn't be using that to set/change the delegate (and get the Obj-C interrupt callbacks).

I guess a possible work-around is to test for the iOS version and in <6.0 set and unset the delegate, and then in 6.0+ listen for the NSNotifications (which won't appear in <6.0, so shouldn't break). However, this seems like a kludge.

Adam Jones
  • 775
  • 6
  • 21
  • This was such a pain. I'm dealing with it now and because I'm using the C API, I'm having even more pain. – kakyo Jul 02 '13 at 15:01

1 Answers1

0

Have you tried calling AudioSessionInitialize and passing NULL to the AudioSessionInterruptionListener (i.e. the function that will be handling the interrupt) when you're done with it?

The interface is as follows:

   OSStatus AudioSessionInitialize (
       CFRunLoopRef                      inRunLoop,
       CFStringRef                       inRunLoopMode,
       AudioSessionInterruptionListener  inInterruptionListener,
       void                              *inClientData
);

The documentation explicitly says:

Your application must call this function before making any other Audio Session Services calls. You may activate and deactivate your audio session as needed (see AudioSessionSetActive), but should initialize it only once.

rmigneco
  • 507
  • 4
  • 16
  • I'm positive that I tried calling AudioSessionInitialize once to activate it (with the Listener parameter filled in) and then I called it again with a NULL for the Listener parameter when I wanted to stop listening - it didn't do jack. That was the frustrating part - I couldn't get it to STOP calling the Listener. I still have to call AVAudioSession setDelegate:nil (which is depreciated in 6) to stop the interrupts and setDelegate:self to turn back on the interrupts again. I will revisit this code again now that my last tester is migrating from iOS 5. – Adam Jones Jul 17 '13 at 14:34
  • Interesting issue. It seems like there should be a C style interface function for Uninitializing the session and the interruption listener. – rmigneco Jul 17 '13 at 19:37