1, 蓝牙听音乐时的同时使用 Wifi性能会降低 ?
敝司蓝牙和Wifi 是共天线设计,通过时分复用进行传输,在用蓝牙耳机听音乐时会占用比较多的蓝牙频宽,如果此时开启Wifi 进行上传下载文件测试,敝司内部的测试数据,Wifi速率将会比不打开蓝牙时降低大概50%左右。
2, A2DP听音乐+PAN 上网时,音乐卡音 ?
这是MTK 的limitation,原因如下:
在我们的stack中l2cap有两个队列用来接收上层的数据:high priority & low priority queue。L2cap在往下层送data的时候会优先送high priority queue里边的数据,通常情况下只有 a2dp会走high priority queue。PAN一开始也走 low priority queue,后来由于一笔bug的原因改成了走high queue,目的是为了保证PAN连接上网时不会断线,且其它设备用PAN上网时,如果打开网页的速度越快,则PAN单位时间内的数据会越多,这样就会导致在a2dp & pan 共存的时候,a2dp 本身数据很大,再加上
强大的pan数据,导致a2dp数据来不及送出去,从而导致音乐听起来不流畅及卡音。
总结: A2DP及PAN的需要得用high priority queue,且都是在2.4Ghz上,也不好避免互相的影响了,所以目前敝司已经把它列为limitation了。这可以想象成PC的各种应用在共用网络,然后再去在线看视屏的话速度会很慢很卡。
3, 手机与蓝牙耳机AVRCP连接过程 ?
AVRCP(AUDIO/VIDEO REMOTE CONTROL PROFILE),实现了从蓝牙耳机端控制手机播放、暂停音乐等一些操作,敝司手机实现了AVRCP的target (TG)角色,蓝牙耳机实现了 controller(CT) 角色,在手机连接上蓝牙耳机A2dp(媒体音频)时,蓝牙耳机会判断后续可能会有音乐播放,这时蓝牙耳机都会主动发起avrcp 的连接过程,所以avrcp连接过程一般都是在A2dp连接成功后进行。
4, 蓝牙耳机/车载歌曲名显示异常问题初步排查 ?
显示歌曲名功能是藉由AVRCP1.3 command交互实现的。android4.2及更早版本并没有支持到AVRCP1.3,只会支持到AVRCP1.0。因此这部分各个厂商需要客制化。目前MTK已经将这部分功能实现,但JB2、JB3、JB5 default没有打开此功能。由于在android 4.2及以前版本上属于客制化部分,因此这部分没有统一的api,需要配合一定的条件才能实现。如下为需要初步排查步骤:
1. 是否有将/mediatek/config/${Project_name}/ProjectConfig.mk 里的MTK_BT_PROFILE_AVRCP13置为yes,如果没有的话将其置为yes,再做下一步确认。
2.是否是MTK release的原生Music apk,如果不是的话则必定会有问题(music有客制化适应AVRCP1.3部分),请先换用MTK Music apk,再做后续看是否有问题,如有问题,再做下一步确认。
3. 请抓取开关蓝牙的bt log,并参照 “FAQ04094 [common]如何解析bt_log?”解开 ,查看其中“[AVRCP] AVRCP V14 complied”中是否为V14,如果是V14则表示底层binary已经支持到AVRCP V1.3, 否则需要提起eService申请patch解决。
5, BLE为何如此省电?
以下解释中,BT代表传统的BR/EDR模式,BLE则代表BT4.0特有的低功耗模式。
1). BLE只会在某个特定的时间点传输数据,而其他时间不会传输数据,有些类似BT的sniffmode(睡眠模式)。
2). BLE改进了一些BT耗电场景,如BLE只有在用户需要建立连线的时候才会发起连线相关的动作并且连接建立时间会在ms级,而BT设备通常情况下会开scan window以便被被人找到或连线且连线建立时间会在s级。这样就将传感器设备设计成需要传输数据时再快速建立连线,如果不需要就直接进入设备省电模式。
3). BLE只会有一个Piconet,拓扑结构比BT的简单,在应用规范设计的时候就比较注意,例如把需要特别省电的传感器设备设计为slave,与相对不需要这么省电的手机等设计另外一种模式为master,slave可以根据需要在某些场景下不去接收master的数据包。