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