我认为至少在CoreAudio级别上我对发生的事情有更好的了解.

I think I have a better idea of what happened, at least at the CoreAudio level.

当应用的音频会话类别为单独环境时，音乐应用的播放事件会触发音频会话中断，类似于闹钟或电话.这 将以"enter-interruption"状态触发应用程序的音频会话中断侦听器回调.

When the app's audio session category is solo-ambient, the music app's play event triggers an audio session interruption similar to an alarm clock or a phone call. This will trigger app's audio session interruption listener callback with the "enter-interruption" state.

但是，音乐应用程序的暂停事件不会像人们期望的那样以退出中断"状态触发侦听器回调.这个丢失的退出电话有效地冻结了我们应用的音频会话.退出控制中心也不会触发它.除了可以使用我上一封电子邮件中提到的firstResponder技巧来阻止物理遥控器之外，物理遥控器也可以使用相同的方法.它不适用于控制中心.

However, the music app's pause event does not trigger the listener callback with the "exit-interruption" state, as one would expect. This missing exit call effectively freezes our app's audio session. Quitting the control centre does not trigger it either. Same thing applies to a physical remote-control, except that the physical remote-control can be blocked using the firstResponder trick said in my last email. It does not work with Control Centre.

除非我缺少明显的东西，否则我深信在命令链中CoreAudio或其他框架中存在两个错误.

Unless I'm missing something obvious, I am more convinced that there are two bugs in either CoreAudio or other frameworks in the chain of command.

错误1:如果首先在那儿打入电话，则无法从音乐遥控器发出音频会话中断收听者的退出电话.

Bug 1: Audio session interruption listener's exit call cannot be made from music remote control if the entrance call is made first there.

错误2:控制中心的音乐遥控器与遥控事件机制不符.

Bug 2: Control Centre's music remote control does not conform to remote-control event mechanism.

我很惊讶没有人报告这一点.

I'm just surprised that no one ever reported this.

我认为除非有人提出不同的建议，否则我将提交错误报告.

I think I'm going to file a bug report unless someone suggests differently.

更新 错误2是错误的警报.在通过iOS7 SDK彻底重建所有内容几次之后，我们发现问题消失了.错误1仍然存在.

UPDATE Bug 2 was a false alarm. After clean rebuilding everything over iOS7 SDK for a couple times, we found that the problem went away. Bug 1 still holds.