基于A(yíng)2DP框架的近距離無(wú)線(xiàn)音頻通信研究
加入技術(shù)交流群
2 消息傳遞機制
該輕型框架模塊協(xié)議層之間的交互是通過(guò)消息傳遞機制來(lái)實(shí)現的，消息的種類(lèi)可分為以下4種。
①請求消息REQ
該消息是上層協(xié)議向下層協(xié)議主動(dòng)發(fā)出的請求。
②確認消息CFM
上層協(xié)議發(fā)出的每個(gè)REQ消息，都會(huì )收到下層協(xié)議發(fā)上來(lái)的確認。
③指示消息IND
該消息是下層協(xié)議向上層協(xié)議主動(dòng)發(fā)起的告知。
④響應消息REP
對于每個(gè)下層協(xié)議主動(dòng)發(fā)上來(lái)的IND消息，上層協(xié)議都對此消息進(jìn)行響應。
圖4 協(xié)議間的消息傳遞
協(xié)議間的消息傳遞如圖4所示。
采用基于消息傳遞機制的實(shí)現方法的優(yōu)點(diǎn)如下：
①協(xié)議層之間交互通過(guò)固定的消息接口，即使上下層協(xié)議模塊升級，也不會(huì )影響本層協(xié)議模塊的功能，有很好的移植性和可復用性。
②各層協(xié)議都是異步通信，可以大大降低擁塞情況的發(fā)生。
③協(xié)議棧進(jìn)程可以在上層管理一個(gè)消息隊列，統一進(jìn)行消息收發(fā)，當消息向下傳遞過(guò)程中遭到拒絕時(shí)，可以實(shí)現消息的重傳功能。
④與每層協(xié)議都用一個(gè)單獨的任務(wù)來(lái)實(shí)現相應功能相比，采用消息機制的方法節省了系統調度時(shí)間，更具有實(shí)時(shí)性，同時(shí)避免了死鎖的發(fā)生。
3 重要數據結構
①消息結構體
消息結構體分為3個(gè)域：發(fā)送模塊Id、接收模塊Id、消息枚舉類(lèi)型。具體定義如下：
typedef struct
{
BT_ModuleId sender;
BT_ModuleId receiver;
BT_Primitive primitive;
} BT_Header；
②流端點(diǎn)結構體
流端點(diǎn)SEP存在于應用層中，而應用層又在A(yíng)VDTP中注冊它的SEP，使其他設備可以發(fā)現和連接。SEP在3個(gè)模塊―A2DP、GAVDP、AVDTP中有著(zhù)不同的結構體類(lèi)型，以適應本層協(xié)議的特殊作用。以A2DP模塊為例，其SEP結構體具體定義如下：
typedef struct
{
GAVDP_Handle streamHandle;
BT_U8 *codecInfoElement;
BT_U8 lengthInfoElements;
AVDT_MediaCodecType codecType;
ChannelConfig configuration;
AVDT_ResponseCode pendingRspCode;
BT_TimerId resendTimerId;
} StreamEndPoint；
4 各模塊主要功能及消息接口
各模塊是通過(guò)自己的消息函數來(lái)接收不同的枚舉消息，并轉向各自的消息處理函數，下面具體分析每個(gè)模塊所實(shí)現功能。
①A2DP模塊
A2DP模塊實(shí)現了通過(guò)GAVDP管理SEP和SEP能力的功能，并且在SRC和SNK之間為音頻流文本設置和配置了流通道。根據A2DP模塊的通信流程把它的消息接口分為6種類(lèi)型：流設置消息，它又可分為對等流端點(diǎn)發(fā)現和流配置兩個(gè)步驟；流通道釋放消息；開(kāi)始/掛起流消息；配置/重新配置消息；發(fā)現/得到能力消息；媒體流開(kāi)始消息。
②GAVDP模塊
GAVDP模塊從多個(gè)使用者角度出發(fā)，管理本地流SEP和SEP能力的注冊，處理從遠程設備發(fā)來(lái)的發(fā)現查詢(xún)請求和得到能力請求，同時(shí)基于用戶(hù)注冊的SEP信息，自動(dòng)發(fā)送響應。
由于GAVDP模塊的功能是上層A2DP模塊的細化，因此可以將GAVDP的消息接口和A2DP模塊的接口類(lèi)型作一致性設計，兩者消息接口類(lèi)型基本相同。
③AVDTP模塊
AVDTP模塊負責建立一個(gè)到遠程藍牙設備的AVDTP信令通道，并借助于A(yíng)VDTP協(xié)議發(fā)送所有的信令命令，同時(shí)為媒體流建立傳輸通道，必要的話(huà)為校驗和報告也建立通道，另外還支持信令和媒體消息的分段。AVDTP模塊數據通信最基本的流程為SEP發(fā)現→獲取SNK能力→數據流配置→數據流建立→數據流開(kāi)始→數據流掛起→數據流重新配置→數據流釋放。相應的SEP在A(yíng)VDTP模塊中的狀態(tài)機如圖5所示。
圖5 SEP在A(yíng)VDTP模塊中的狀態(tài)機
整個(gè)通信過(guò)程各個(gè)狀態(tài)之間的躍遷靠下列消息來(lái)觸發(fā)：
A：AVDT_SET_CONFIGURATION _REQ
B：AVDT_OPEN_REQ
C：AVDT_START_REQ
D：AVDT_SUSPEND_REQ
E：AVDT_CLOSE_REQ
F：AVDT_ABORT_REQ
G：AVDT_RECONFIGURE_REQ
H：AVDT_MEDIA_REQ
在空閑狀態(tài)下，發(fā)送A消息之前，空閑狀態(tài)下要發(fā)出一系列動(dòng)作，包括連接請求、發(fā)現請求和獲取SNK能力請求等。從空閑態(tài)到配置態(tài)的躍遷過(guò)程，本協(xié)議棧統稱(chēng)為流設置過(guò)程。
在打開(kāi)狀態(tài)下發(fā)送C消息之后，就進(jìn)入了流控狀態(tài)，此時(shí)通過(guò)H消息就可以發(fā)送從SRC到SNK的媒體流數據包。
在通信過(guò)程中的任何狀態(tài)下，都可以通過(guò)發(fā)送F消息，進(jìn)入中止態(tài)，進(jìn)而回到?jīng)]有連接任何遠程SEP的空閑狀態(tài)。
測試及結論
該輕型協(xié)議棧的實(shí)現與測試，可以基于CSR先進(jìn)的BlueCore4藍牙芯片來(lái)完成。該芯片支持藍牙2.0+EDR規范，并提供2.1Mb/s的數據傳輸速率，比標準藍牙快3倍，可實(shí)現更快速的連接，同步支持多個(gè)藍牙鏈路，以及音頻流等更寬帶寬的新興應用。最上層的音頻應用程序實(shí)現了一個(gè)簡(jiǎn)單的具有處理SBC格式編解碼信息的播放器，該應用程序和部分高層協(xié)議棧通過(guò)交叉編譯，下載到硬件平臺主機端。而播放器程序是通過(guò)調用本協(xié)議棧提供的API，進(jìn)行音頻數據流分發(fā)。對于音頻數據的接收端SNK，采用摩托羅拉HT820立體聲耳機進(jìn)行測試，在長(cháng)時(shí)間播放音頻數據的情況下，仍然會(huì )存在音頻停頓的現象。使用一種截獲空中藍牙信號并進(jìn)行協(xié)議分析的工具Airsniffer，抓取流媒體傳輸數據包，經(jīng)分析，音頻數據并未丟失，而是流控機制存在問(wèn)題，需要進(jìn)一步完善。
評論