Qualcomm蓝牙耳机FAQ(39)----LE audio Broadcast应用与实测数据

大家好！欢迎大家登录大大通平台，随着市场需求，大家对broadcast的应用需求是越来越强烈，

今天我在之前博文的基础上给大家讲解基于QCC平台的LE Audio broadcast的应用，以及我们在实验室测试的各项数据，提供给大家参考。

在LE audio的broadcast产品的应用上，source端一直维持broadcast的状态，耳机端通过手机搜索周边的所有broadcast发射源，

通过手机来选择耳机与那个broadcast 源连接，手机就会将该源的sid以及UUID传给耳机发起连接。

 

目前市面上LE audio的broadcast还不成熟，手机也还没有，我们可以通过python指令来模拟。

------------------------------------------实测开始------------------------------------------------

在ADK R593.1上测试,用QCC3086或者QCC5181做broadcast发送源； QCC518x、QCC308x、QCC307x做接收测试：

Source端修改软件如下：

修改编译烧录到EVB上后，通过python调用appTestBroadcastModeEnable()，让dongle一直处于broadcast 状态。

HEADSET 端修改如下：

1、修改le_broadcast_manager_source.c文件

2、修改le_broadcast_media_control.c文件

修改完成之后，编译烧录到EVB上。

3.在headset端调用命令,去搜索broadcast源:

apps1.fw.call.leBroadcastManager_StartScanForPaSource(1)

 
4.在headset的live log中找到:

2023-08-02 14:40:35.740049 A: 79: leBroadcastManager_EaReportReceived data_len=0x28 sid=0xf

2023-08-02 14:40:35.740118 A: 7D: leBroadcastManager_EaReportReceived Found BAA Service Data UUID: Broadcast_ID:0xf414

 

5.把上面两个参数0xf和0xf414分别填到以下函数并调用:

LeBroadcastManager_LocallyAddBroadcastSource(0xf,0xf414)

 

6.这时就可以听到headset端的音乐了.

LE AUDIO broadcast source端链路分析

从上图的broadcast Stream chain可以看出整个source 端只有TTP和IIR_RESAMPLER两个主要模块，然后经过两个LC3 ENCODE模块输出左右声道到发射端。

从上图的IIR_RESAMPLER模块可以得知当前的source端输入和输出的格式都是16bit 48K。

从source端的live_log也可以看出采样率也是48k    sample_rate:48000

LE Audio broadcast HEADSET端链路分析:

从headset的Streams chain 链路可以看出，接收端经过两个LC3_DECODE模块解码出接收到到的音频数据后，经过EQ调整直接输出了。

从输出端AUDIO SINK模块上可以看出，输出后的LC3格式是16bit 48K。

从headset端的live_log也可以看出接收端的采样率是48000 params->sample_rate=48000

 

LE AUDIO broadcast延时性测试：

测试方法：

• 选QCC3086或者QCC5181做发射源，添加INCLUDE_LE_AUDIO_ANALOG_SOURCE配置为LineIn模拟输入。
• 通过AP的out put连接到Source的输入端。
• 通过broadcast的方式，连接多个接收设备。
• 将一个接受设备的输出端，接到AP的输入端，这样就可以形成一个回路。

 AP发出一个指定的声音--> Source的输入-->通过broadcast 传输给接收设备-->接收设备输出端传输给AP的输入端。

这样AP就可以通过自己输出的声音和接收到的声音计算出一个时间差，从而得到整个回路的延时。

经过测试发现，得出如下结论：

• 在同一个broadcast源下，和设备多少没关系，到每一个的设备的延时都是固定的。
• 重启broadcast源，再重新连接设备，每次的延时都有一些差异，但是相差在12ms范围之内。
• 测试当前TWS（QCC3071）设备,其主耳的延时和外设的设备延时一致，副耳的延时要比主耳的多10ms(具体原因待查)。
• 按照上述的方式测试，我们得到的延时是在57ms~68ms之间。

      


今天的博文就讲解到这，大家在对我上述的说明有任何疑问可以来我们公司一块讨论，欢迎大家的指导和建议！！！


关注大大通！关注大大通！！关注大大通！！！ 知识不容错过。


问题1：你们测试的ADK是那个版本？

答：采用的是ADK-23.1-CS1-r00593.1这个版本的软件。

 

问题2：上图的chain链路图，是怎么调出来的？

答：可以参考我们之前有关KSP描述的博文，具体的也可以咨询我们大联大的FAE。

 

问题3：LE Audio的接收设备最多可以支持多少？

答：我们的LE Audio broadcast 应用一个source可以支持N个接收设备，而且不会有什么影响。欢迎大家来我们公司体验。

 

问题4：你的延时测试机制准吗？

答：目前基于我们当前有限的条件，这个机制的测试方法只能测试source输入到headset输出的整个链路的延时，包含了蓝牙系统的延时以及空中传输的延时等等，具体各个环节的测试，大家可以来我们实验室一块验证。

 

问题5：LE Audio broadcst 技术成熟吗？有客户量产吗？

答：当前LE Audio broadcast 技术QCC应该算是最稳定的了，而且底层也是全开放的，大家可以随意开发。欢迎大家来我们公司一块学习。