DIY编程器网

标题: 如何在单个蓝牙设备上集成语音和立体声音乐功能 [打印本页]
作者: admin    时间: 2014-10-13 09:08
标题: 如何在单个蓝牙设备上集成语音和立体声音乐功能
业界预测蓝牙立体声将成为增长最快的市场-并将占据第二的位置。其结果是，设计师将在蓝牙设备附件中集成蓝牙功能和“随身”音乐功能，特别是在播放流媒体音乐的立体声耳机上。说起来容易做起来难。要提供具有吸引力的音乐和立体声蓝牙设备，还有许多挑战需要克服。本文将详细讨论这些挑战，并提供解决这些问题的建议。
        可以说没有人怀疑蓝牙音乐的前途一片光明。在2005年的第一季度，几乎所有的顶级手机提供商都推出或启动支持音乐的移动电话-诺基亚在4月推出了N91型号的手机，索尼-爱立信在3月的CeBit上发布了随身听(Walkman)手机，在同一展会上，三星公司发布了SGHi300，而摩托罗拉公司的iTune版移动电话也成为媒体的头条。
        但是，还存在另一个必须面对的事实，即蓝牙立体声耳机的普及要落后于移动音乐的发展速度，从而使得上述的好消息打了折扣。其原因并不难理解。随着蓝牙已成为短距离手机无线传输的事实标准，而且单声道蓝牙耳机已日益普及，用户并不希望使用两套蓝牙音频设备-一套用于通话，而另外一套用于立体声(音乐播放器)。
蓝牙音频耳机设备分类
        关于蓝牙音频设备，定义上可以分为如下三种：
1.蓝牙单声道(语音)耳机：这种耳机出货已经有一段时间了，成熟度已经很高。蓝牙单声道耳机是一种小型的蓝牙设备，用户可以用它进行免提通话。
2.蓝牙立体声耳机：这类耳机只允许使用者欣赏立体声音乐。
3.蓝牙立体声耳机套件：该在套件允许使用者在欣赏立体声音乐的同时进行免提通话。状态切换涉及到在立体声耳机中将音乐流媒体状态平滑地切换到语音通话状态，并且在通话结束后再切换回音乐流状态。


图1：分散网络的实例。



图2：微微网络的实例

蓝牙应用场景分类
        与蓝牙立体声和蓝牙语音相关的用户应用情景有很多种，不过其中大多数可以归纳为以下两种情形：
1. 音乐播放器-移动电话连接：某个用户正在使用蓝牙立体声耳机听音乐，这时移动电话有电话呼入。这时音乐将自动暂停，她可以在耳机中听到电话铃声，然后接听电话。挂断电话后，音乐马上从先前暂停的地方继续播放。上述用户情景大多数要求蓝牙立体声耳机成为两个微微网中的公共设备。在其中一个网络中，移动电话需要成为主设备，音乐播放器则是另外一个网络中的从设备。蓝牙立体声耳机套件本身则成为其中一个微微网络中的主设备，另外一个网络中的从设备，从而形成一个分散式网络。在某些情况下，可能不会形成分散网络，此时蓝牙立体声耳机套件将成为主设备。
2. 多媒体电话连接：用户正在利用支持音乐的最新蓝牙移动电话欣赏无线音乐。这时他的话机上显示有个电话呼入；话机音乐暂停，随之蓝牙立体声耳机声音停止。通过使用蓝牙立体声耳机上的“通话”按钮进行通话。当通话一结束，音乐自动地从暂停的地方继续播放。这种情景将创建有两个设备的单个微微网络。
用户体验所面临的挑战
        表面上看起来这两种应用都比较简单--暂停音乐、接听电话、通话结束后立即恢复音乐的播放。实际没那么简单。在蓝牙耳机套件中集成语音和立体声功能，同时提供简单和直观的用户体验充满了挑战。这些挑战包括以下三类：
1. 技术挑战：这些问题与蓝牙规范相关，要么不足以解决这些问题，要么就是不够明确。例如，当用于流媒体音乐的ACL链路已经存在时，是不可能建立HV1 SCO链路进行通话的。HV1数据包类型需要占用整个带宽。
2. 实现挑战：这些问题与规范的解释以及随后实现强制性或可选性功能有关。例如，很多移动电话每当有按键按下时都将建立一个SCO连接。为了在蓝牙立体声耳机中听到话机上有键按下，耳机中的音乐每隔若干毫秒就需要暂停一下，这将产生一种令人沮丧的用户体验。
3. 指导原则的缺乏：因为某些时候规范并不充分或不够清楚，而大量公司又迫不及待地在他们的产品中实现这些规范，因此业界急需蓝牙语音和音乐共存的指导原则。直到最近，蓝牙SIG和相关公司才意识到蓝牙立体声耳机应用所展示的巨大机会。多家蓝牙组织已经开始去解决蓝牙立体声与语音功能的共存和互操作性问题。
问题并非在于技术本身
        仔细分析上述应用中所遇到的种种挑战，发现问题的核心并非在于技术本身。蓝牙立体声耳机套件是蓝牙功能集成的中心。对于音乐播放器和移动电话连接而言，蓝牙立体声耳机套件是移动电话和音乐播放器之间的连接链路，对于多媒体电话连接，即使移动电话可能知道SCO和ACL两个链路，在管理切换上蓝牙立体声耳机套件也扮演着关键的角色。
        如前面讨论的那样，用户体验涉及到暂停音乐、在耳机上播放铃声，根据用户的喜好接听或不接听，以及通话结束后恢复播放音乐。蓝牙立体声耳机单独地处理暂停和恢复顺序。类似地，蓝牙单声道耳机也能单独地处理语音顺序。挑战在于将这些功能放在一起。
        最初的音频-视频遥控协议(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数据包类型+流静音的顺序图表。



图11：移动电话上SCO Beep的顺序图表。

        非理想实现导致的另外一个问题是按键动作的处理。当音乐在ACL链路上传送时移动电话的任何按键动作都会发出嘟嘟声响。这时，用户的体验很不爽。因为每当有按键按下，在蓝牙立体声耳机套件中将发出哔音，这需要暂停音乐，切换到SCO连接，播放哔声，恢复播放音乐，当下一次按键按下时再次中断。一种变通的方法是要求用户禁止移动电话上的按键哔声提示音。这既不合理也是有代价的，它要求支持电话、文档和用户教育，因此是不可接受的。
        有几种配置需要蓝牙立体声耳机和蓝牙单声道耳机分别加以考虑。当蓝牙立体声和蓝牙单声道功能需要同时存在时，这些配置累加会导致蓝牙立体声耳机套件设计的复杂性迅速增加。
        过去，移动电话提供商在做出产品选择时，需要根据不同的移动电话使用情形证明其合理性。一个例子是选用HV1包类型可以获得比HV3包类型更好的质量。类似地，蓝牙音乐播放器提供商做出了在很少的使用情形下表现不错的选择-例如使用流静音实现AVRCP暂停/播放。这种选择带来的局限性被证明在立体声-单声道共存的情况下代价是很高的。最近蓝牙SIG下面成立的AV-HFP工作组有望帮助解决这个问题。
其它方面的挑战
        还有以下系统问题需要在蓝牙立体声耳机套件设计中加以解决。
1. 管理在切换期间单芯片方案中的MIPS需求。MIPS负载可能占用单芯片方案90%~95%的处理能力，因为大多数蓝牙基带针对成本进行了优化设计。必须小心处理这种峰值MIPS负载。
2. 管理切换时的抖动。尽管对于无线流传输来说抖动总是一个主要的挑战，但在切换时将变得特别严重。加之峰值MIPS负载，这个问题特别难于解决。
3. 延时。延时需要尽可能小，这样才可以给用户近似于有线连接的体验。这个问题有两个方面：呼叫进入和通话结束后的音乐恢复。对于第一种情况，如果延时很长，可能不能及时接通电话，而对于后者，用户可能会觉得在切换期间音乐丢失了。对于任何一种情况，用户体验都将受到影响。
        总之，蓝牙音乐和语音的共存要求带来了技术和非技术两方面的各种挑战。不过令人欣慰的是，这些挑战并非是不可解决的，因为这些挑战主要与每个公司的实现选择和缺乏一致的指导原则有关。这些挑战已经得到业界的全面认识，并正在得到解决。通过像蓝牙SIG这些组织的协调以及每个公司的努力，完全可能将应用前景转变成技术和商业上的成功故事。
作者：Yogesh Kamat Mhamai
高级软件工程师
Bikash Chowdhury
无线立体声项目经理
Impulsesoft



欢迎光临 DIY编程器网 (http://diybcq.com/) Powered by Discuz! X3.2