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應該算是最穩定的了，而且底層也是全開放的，大家可以隨意開發。歡迎大家來我們公司一塊學習。