大家好！歡迎大家登錄大大通平台，隨著市場需求，大家對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應該算是最穩定的了，而且底層也是全開放的，大家可以隨意開發。歡迎大家來我們公司一塊學習。
評論