如何在单个蓝牙设备上集成语音和立体声音乐功能

验涉及到暂停音乐、在耳机上播放铃声，根据用户的喜好接听或不接听，以及通话结束后恢复播放音乐。蓝牙立体声耳机单独地处理暂停和恢复顺序。类似地，蓝牙单声道耳机也能单独地处理语音顺序。挑战在于将这些功能放在一起。

最初的音频-视频遥控协议(AVRCP)命令暂停(Pause)和播放(Play)的语言并不与高级音频分配协议(A2DP)连接严格关联。目前在系统中集成蓝牙立体声功能的音乐播放器在接收暂停命令时采用了下面三种选择之一：1. 待机/启动；2. 断开/连接；3. 流静音。

待机/启动是AVRCP暂停和播放命令的理想实现方式，如图3所显示。然而在图3中的A2DP待机/启动是可选命令，在很多方案中并没有实现。这导致了下面之一作为变通的情形。

图3：使用A2DP待机/启动的AVRCP暂停/播放实现。

断开/连接是一种强制命令，不受可选的待机/启动命令所面临的问题影响。该选项显示在图4中。

图4：使用A2DP断开/连接的AVRCP暂停/播放实现

这种方式受两个主要的缺陷影响。AVRCP暂停/播放语义不严格对应断开/连接。它还因为重新连接的协议协商(所有编解码参数重新协商)导致更高的延时，好像是一个新的连接一样。

流静音是另外一种方法，可以用于实现AVRCP暂停/播放语义。当蓝牙立体声耳机套件调用AVRCP暂停命令时，蓝牙音乐播放可以开始流静音，对用户而言，音乐将表现为已经暂停。图5中显示了这个选项。

图5：使用流静音的AVRCP暂停/播放实现

事实上，这是AVRCP暂停/播放的模拟情形。这可能是一种可行的方案，当待机/启动没有实现，对于可以接受的用户体验来说，与断开/连接相关的延时可能太长了。

值得注意的是，与实现AVRCP暂停/播放语义所采用的方法无关，最终用户可能不会体验到真正的暂停/播放行为，即音乐从它最初停止的地方恢复，除非蓝牙AV子系统具有到音乐播放器的数字接口，以及用于控制音乐播放器状态的节目接口。

通过上述所有这些分析可以得出以下的结论，即蓝牙音乐播放器用于解决AVRCP暂停/播放语义的方法并不一致。缺乏一致认可的规则是导致蓝牙立体声耳机设计和实现复杂度增加的原因。

关键在于实现

除了上述的问题之外，移动电话方面的问题也是难题的一部分。在单声道领域，移动电话提供商采用了简单的方法来使语音质量达到最佳，并认为这样是可行的。今天，全球有超过1亿部移动电话支持蓝牙。然而，这些移动电话在蓝牙语音实现上千差万别。例如，某些移动电话需要在呼叫进入时建立ACL+SCO连接，而某些要求ACL连接一直打开，只有在有电话呼入时才建立SCO连接；也有一些方案让SCO连接始终打开。此外，不同电话供应商以及同一个供应商的不同型号的移动电话支持的SCO包类型(HV1、HV2、HV3)可能都不相同。如图6所示。

图6：已经得到解决并基于移动电话的蓝牙通话情景。

图7和图8显示了在呼叫进入时和ACL连接始终打开的ACL顺序图表。

图7：呼叫进入时的ACL链路

图8：ACL链路处于常开状态

蓝牙立体声耳机套件设计师需要解决的音乐播放器和移动电话的真实配置主要源于音乐播放器和/或移动电话提供商的实现选择。

考虑一个用A2DP待机/启动实现AVRCP暂停/播放的例子，移动电话的ACL链路保持接通(呼叫进入时SCO连接)，并且只支持HV1包。如果蓝牙立体声耳机套件的音乐流速度为350kbps，蓝牙立体声耳机套件中的蓝牙基带将拒绝任何HV1包类型的SCO连接请求。这是因为HV1包类型需要占用整个带宽，HV1包是一种单时隙包类型，带有10个信息字节，需要在每两个时隙内传递；微微网主设备需要1个时隙来发送HV1包，另外一个时隙用于接收HV1包，因此完全占用了整个带宽。在速度为350kbps(在理想的情形下，当呼叫进入时将最终进入到待机模式)的已有ACL连接中，蓝牙立体声耳机套件中的蓝牙基带知道不能满足HV1包类型的并发SCO链接需求，因此会拒绝SCO连接请求。这对于只支持HV1包类型的移动电话来说，明显是一个很大的问题。图9显示了HV1 SCO包类型连接+待机/启动的顺序图表。

图9：HV1 SCO包类型连接+待机/启动的顺序图表。

设想蓝牙移动电话支持HV3包类型的另外一种情形。蓝牙立体声耳机套件中的蓝牙基带将接受进入的连接-微微网主设备需要一个时隙来发送HV3数据包，下一个时隙来接收HV3包，在主设备需要发送接下来的HV3包之前，下4个时隙以及带宽将可用。然而，如果蓝牙音乐播放器使用流静音机制实现了AVRCP暂停/播放，蓝牙立体声耳机套件在管理同时发送数据(静音)和SCO连接的ACL链路时将出现问题。

图10：HV3 SCO数据包类型+流静音的顺序图表。