Playing using MPMusicPlayerController.applicationMusicPlayer triggers AVAudioSession interruption
| Originator: | jay.whitsitt | ||
| Number: | rdar://28431676 | Date Originated: | 22 Sept 2016 |
| Status: | Open | Resolved: | |
| Product: | iOS SDK | Product Version: | |
| Classification: | Other Bug | Reproducible: | Always |
Summary: Playing music from Apple Music using the MPMusicPlayerController class works, but when I have called [AVAudioSession setActive:YES] before calling play on the MPMusicPlayerController class, I get an AVAudioSessionInterruptionNotification. I am using the applicationMusicPlayer, not systemMusicPlayer, so I expect to handle the audio session myself because of this documentation: https://developer.apple.com/reference/mediaplayer/mpmusicplayercontroller >To receive remote-control events in your app, you must use an application music player. If >you use the system music player, your app uses the Music app to play audio, which means >that the Music app is the “now playing” app. I do realize this didn't mention handling the AVAudioSession and I haven't found documentation explicitly saying whether an applicationMusicPlayer will handle the AVAudioSession for me. However, handling remote events but not the actual audio session on my behalf is unintuitive. If what's happening is expected, this will not work for my use case as I am also playing audio outside Apple Music using URLs and other audio player frameworks that don't handle the AVAudioSession for me. It would be impossible to differentiate an interruption from the MPMusicPlayerController starting playback and another app trying to stop my app. Steps to Reproduce: [AVAudioSession setActive:YES]; self.playerController = [MPMusicPlayerController applicationMusicPlayer]; [self.playerController setQueueWithStoreIDs:@[trackId]]; [self.playerController play]; Expected Results: No AVAudioSessionInterruptionNotification notification Actual Results: I received an AVAudioSessionInterruptionNotification Version: iOS 10.0.1, Xcode 8.0, OS X El Capitan 10.11.6 Notes: Configuration: iPhone 6, Project Fi Attachments:
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
Reply to Apple
I have confirmed that applicationMusicPlayer is acting as systemMusicPlayer in many cases still in 10.1.1. In all of these scenarios, my app has used applicationMusicPlayer, not systemMusicPlayer.
Reply to Apple
To confirm, none of this functionality changes when using applicationMusicPlayer vs systemMusicPlayer?
• The documentation says that if using applicationMusicPlayer, my app needs to handle the remote control events.
• Also, the quote I mentioned in my original bug summary states that systemMusicPlayer makes the Music app the "now playing" app. This implies that applicationMusicPlayer makes my app the "now playing" app. Those two seem contradictory but I realize I'm making assumptions not explicitly supported in documentation.
Regardless, my app is not receiving remote control events after receiving the interruption, so it's as if my app is completely disconnected from all audio-related functions. I can still make calls to MPMusicPlayerController to alter playback state.
Apple Developer Relations
Engineering has the following feedback for you:
You are using your app to play audio using the shared instance of AVAudioSession.
Then you trigger remote playback of Apple Music using MPMusicPlayerController.
Obviously this interrupts the app’s AVAudioSession unless the AVAudioSession is set to mixWithOthers. So one recommendation is for upi to use the AVAudioSessionCategoryOptions mixWithOthers. This way he won’t be interrupted.
But at a time, only one app can show up in the control center. And in this case the right app in the control center ia Apple Music.
Thank you for your feedback, it is noted. Engineering has determined that there are currently no plans to address this issue.
We are now closing this bug report.
If you have questions or comments about the resolution, please update your bug report with that information so we can respond.