基于A2DP框架的近距離無線音頻通信研究

基于A2DP框架的近距離無線音頻通信研究

隨著藍牙技術(shù)在電子產(chǎn)品中的日益普及，藍牙音頻設(shè)備也層出不窮，其中具有免提功能的藍牙耳機和藍牙音頻網(wǎng)關(guān)的應(yīng)用是最典型的例子。但免提單元與音頻網(wǎng)關(guān)進行音頻傳輸建立起來的SCO連接，僅能支持64Kb/s電信級語音質(zhì)量的音頻流，這也就限制了藍牙音頻質(zhì)量的提高，同時也影響了藍牙的娛樂消費市場。為了滿足人們對高質(zhì)量音頻的需求，進一步擴大藍牙產(chǎn)品市場，藍牙特殊興趣小組SIG組織，在藍牙? 1.1規(guī)范的應(yīng)用框架基礎(chǔ)上又單獨提出了高級音頻分發(fā)框架（Advanced Audio Distribution Profile，A2DP）。該框架利用了在L2CAP層建立起來的ACL異步無連接鏈路來傳輸高質(zhì)量的單聲道或者立體聲音頻數(shù)據(jù)，有效負載的傳輸速率可以達到300～400Kb/s。

A2DP框架概述
在娛樂消費市場中，A2DP實例化應(yīng)用就是用音樂播放器把音頻數(shù)據(jù)通過ACL連接發(fā)送到耳機或者音箱上。目前的框架規(guī)范中，并不支持同步的一點對多點的廣播式音頻分發(fā)，而對于點對點音頻的分發(fā)，又存在著兩種不同的角色，一個是信源設(shè)備（SRC），這種設(shè)備作為發(fā)起者將數(shù)字音頻流發(fā)送到Piconet網(wǎng)中；另一個是信宿設(shè)備，是接收信源發(fā)出的音頻流的設(shè)備。如果藍牙音樂播放器是信源設(shè)備，那么與之交互的藍牙耳機就是信宿設(shè)備，信源和信宿的區(qū)別就在于，它是發(fā)起者還是接收者。下面對該框架所涉及的具體協(xié)議和其依賴框架進行分析。

1 A2DP應(yīng)用框架
在典型的藍牙音頻相關(guān)框架的整體結(jié)構(gòu)中，A2DP框架所處的位置如圖1所示。
服務(wù)發(fā)現(xiàn)應(yīng)用框架（SDAP）所提供的功能，是向其他藍牙設(shè)備提供自身所具備的服務(wù)，并且能夠使用遠程設(shè)備所提供的服務(wù)和功能。在實際應(yīng)用中，幾乎所有框架都支持服務(wù)發(fā)現(xiàn)協(xié)議（SDP）。藍牙音頻視頻遙控應(yīng)用框架（AVRCP）實現(xiàn)了藍牙設(shè)備之間的遙控功能，例如，音樂播放器的前進、后退、停止、播放等控制信令的傳輸。免提功能頭戴式設(shè)備應(yīng)用框架（HFP/HSP），最主要的應(yīng)用就是實現(xiàn)了藍牙耳機的免提功能和某些藍牙設(shè)備的音頻網(wǎng)關(guān)功能。

高級音頻分發(fā)框架（A2DP）依賴于通用音頻視頻分發(fā)框架（GAVDP），GAVDP定義了設(shè)置音頻和視頻流傳輸?shù)牟襟E，而A2DP則進一步定義了音頻流傳輸?shù)?a target="_blank">參數(shù)和步驟細節(jié)。

在實際應(yīng)用中，邏輯鏈路控制適配層協(xié)議（L2CAP）要求比較高的可靠性，基帶的廣播數(shù)據(jù)分組將被禁止使用，因此，L2CAP層并不支持可靠的多點傳輸信道，這也就是A2DP框架不支持多點廣播式音頻分發(fā)的主要原因之一。而對于面向高層協(xié)議的開發(fā)和應(yīng)用者，L2CAP層協(xié)議是透明的，因此這里對A2DP輕型框架具體實現(xiàn)的相關(guān)描述，也僅限于L2CAP層以上，A2DP相關(guān)的協(xié)議及框架如AVDTP、GAVDP等協(xié)議模塊的設(shè)計。

圖1 藍牙音頻框架整體結(jié)構(gòu)

圖1中的藍牙主機控制接口HCI層，是協(xié)議棧中軟硬件的接口。這里所涉及的硬件環(huán)境是主機與主機控制器連接模型，HCI層以上的協(xié)議（如SDP）在主機上運行，而以下的協(xié)議（如傳輸層的藍牙基帶協(xié)議等）由藍牙主機控制器硬件來完成，這樣既保證了底層協(xié)議傳輸?shù)姆€(wěn)定性，又支持了上層應(yīng)用協(xié)議的可擴展性。一旦在市場條件成熟，藍牙技術(shù)的硬件部分就可以被更快的硬件射頻技術(shù)所取代，高層傳輸協(xié)議經(jīng)過移植仍然可以沿襲使用，大大縮短藍牙產(chǎn)品的研發(fā)周期。

2 A2DP框架協(xié)議棧
A2DP是音頻傳輸框架，它通過藍牙傳輸層和對等設(shè)備，把音頻數(shù)據(jù)流從音頻信源（SRC）到音頻信宿（SNK）進行分發(fā)，因此該框架所包含的協(xié)議棧也分為兩個部分，具體表現(xiàn)如圖2所示。

圖2 A2DP框架協(xié)議棧

基帶協(xié)議（Baseband Protocol）、鏈路管理協(xié)議（LMP）、邏輯鏈路控制和適配協(xié)議（L2CAP）及服務(wù)發(fā)現(xiàn)協(xié)議（SDP），在藍牙核心協(xié)議規(guī)范中都有定義。而藍牙音頻視頻分發(fā)傳輸協(xié)議AVDTP則定義了藍牙設(shè)備之間數(shù)據(jù)流句柄的參數(shù)協(xié)商、建立和傳輸過程以及相互交換的信令實體形式，該協(xié)議是A2DP框架的基礎(chǔ)協(xié)議。

輕型A2DP框架協(xié)議實現(xiàn)
這里所提出的A2DP框架協(xié)議的實現(xiàn)集中在音頻信源端，并未設(shè)計信宿端。之所以定義為輕型的，是因為在A2DP規(guī)范1.0基礎(chǔ)之上，實現(xiàn)了此規(guī)范所規(guī)定的強制性功能，即在信源端僅僅實現(xiàn)了高級音頻分發(fā)的基本功能，如立體聲音頻的傳輸，只支持低復(fù)雜度子帶編解碼（SBC）標準，而對其他編解碼標準并未涉及；在A2DP模塊的實現(xiàn)中并未包括任何的編解碼能力，這是在用戶層上實現(xiàn)的，是上層應(yīng)用程序在設(shè)置階段，通過配置協(xié)商來做相應(yīng)的編碼，解碼和音頻內(nèi)容的轉(zhuǎn)換工作；AVDTP模塊的功能不包括校驗和報告，也不包括媒體多路復(fù)用，校驗和報告通道的建立。

1 協(xié)議模塊劃分
A2DP框架協(xié)議劃分了3個模塊：A2DP模塊、GAVDP模塊和AVDTP模塊，另外還包括測試協(xié)議棧所需要的Audio應(yīng)用程序測試模塊。對于GAVDP，雖然該功能模塊包括音頻/視頻兩種數(shù)據(jù)流的傳輸與分發(fā)，但是由于這里側(cè)重對音頻流進行討論，所以視頻流相關(guān)模塊（VDP）并未實現(xiàn)。圖3是具體實現(xiàn)模塊劃分圖。

圖3 A2DP框架具體模塊劃分

2 消息傳遞機制
該輕型框架模塊協(xié)議層之間的交互是通過消息傳遞機制來實現(xiàn)的，消息的種類可分為以下4種。
①請求消息REQ
該消息是上層協(xié)議向下層協(xié)議主動發(fā)出的請求。
②確認消息CFM
上層協(xié)議發(fā)出的每個REQ消息，都會收到下層協(xié)議發(fā)上來的確認。
③指示消息IND
該消息是下層協(xié)議向上層協(xié)議主動發(fā)起的告知。
④響應(yīng)消息REP
對于每個下層協(xié)議主動發(fā)上來的IND消息，上層協(xié)議都對此消息進行響應(yīng)。

圖4 協(xié)議間的消息傳遞

協(xié)議間的消息傳遞如圖4所示。
采用基于消息傳遞機制的實現(xiàn)方法的優(yōu)點如下：
①協(xié)議層之間交互通過固定的消息接口，即使上下層協(xié)議模塊升級，也不會影響本層協(xié)議模塊的功能，有很好的移植性和可復(fù)用性。
②各層協(xié)議都是異步通信，可以大大降低擁塞情況的發(fā)生。
③協(xié)議棧進程可以在上層管理一個消息隊列，統(tǒng)一進行消息收發(fā)，當消息向下傳遞過程中遭到拒絕時，可以實現(xiàn)消息的重傳功能。
④與每層協(xié)議都用一個單獨的任務(wù)來實現(xiàn)相應(yīng)功能相比，采用消息機制的方法節(jié)省了系統(tǒng)調(diào)度時間，更具有實時性，同時避免了死鎖的發(fā)生。
3 重要數(shù)據(jù)結(jié)構(gòu)
①消息結(jié)構(gòu)體
消息結(jié)構(gòu)體分為3個域：發(fā)送模塊Id、接收模塊Id、消息枚舉類型。具體定義如下：
typedef struct
{
?BT_ModuleId　sender;
?BT_ModuleId　receiver;
?BT_Primitive????? primitive;
} BT_Header；
②流端點結(jié)構(gòu)體
流端點SEP存在于應(yīng)用層中，而應(yīng)用層又在AVDTP中注冊它的SEP，使其他設(shè)備可以發(fā)現(xiàn)和連接。SEP在3個模塊—A2DP、GAVDP、AVDTP中有著不同的結(jié)構(gòu)體類型，以適應(yīng)本層協(xié)議的特殊作用。以A2DP模塊為例，其SEP結(jié)構(gòu)體具體定義如下：
typedef struct
{
GAVDP_Handle? streamHandle;
BT_U8???? *codecInfoElement;
BT_U8?? lengthInfoElements;
AVDT_MediaCodecType???? codecType;
ChannelConfig?? configuration;
AVDT_ResponseCode??? pendingRspCode;
BT_TimerId?? resendTimerId;
} StreamEndPoint；
4 各模塊主要功能及消息接口
各模塊是通過自己的消息函數(shù)來接收不同的枚舉消息，并轉(zhuǎn)向各自的消息處理函數(shù)，下面具體分析每個模塊所實現(xiàn)功能。
①A2DP模塊
A2DP模塊實現(xiàn)了通過GAVDP管理SEP和SEP能力的功能，并且在SRC和SNK之間為音頻流文本設(shè)置和配置了流通道。根據(jù)A2DP模塊的通信流程把它的消息接口分為6種類型：流設(shè)置消息，它又可分為對等流端點發(fā)現(xiàn)和流配置兩個步驟；流通道釋放消息；開始/掛起流消息；配置/重新配置消息；發(fā)現(xiàn)/得到能力消息；媒體流開始消息。
②GAVDP模塊
GAVDP模塊從多個使用者角度出發(fā)，管理本地流SEP和SEP能力的注冊，處理從遠程設(shè)備發(fā)來的發(fā)現(xiàn)查詢請求和得到能力請求，同時基于用戶注冊的SEP信息，自動發(fā)送響應(yīng)。
由于GAVDP模塊的功能是上層A2DP模塊的細化，因此可以將GAVDP的消息接口和A2DP模塊的接口類型作一致性設(shè)計，兩者消息接口類型基本相同。
③AVDTP模塊
AVDTP模塊負責建立一個到遠程藍牙設(shè)備的AVDTP信令通道，并借助于AVDTP協(xié)議發(fā)送所有的信令命令，同時為媒體流建立傳輸通道，必要的話為校驗和報告也建立通道，另外還支持信令和媒體消息的分段。AVDTP模塊數(shù)據(jù)通信最基本的流程為SEP發(fā)現(xiàn)→獲取SNK能力→數(shù)據(jù)流配置→數(shù)據(jù)流建立→數(shù)據(jù)流開始→數(shù)據(jù)流掛起→數(shù)據(jù)流重新配置→數(shù)據(jù)流釋放。相應(yīng)的SEP在AVDTP模塊中的狀態(tài)機如圖5所示。

圖5 SEP在AVDTP模塊中的狀態(tài)機

整個通信過程各個狀態(tà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ā)出一系列動作，包括連接請求、發(fā)現(xiàn)請求和獲取SNK能力請求等。從空閑態(tài)到配置態(tài)的躍遷過程，本協(xié)議棧統(tǒng)稱為流設(shè)置過程。

在打開狀態(tài)下發(fā)送C消息之后，就進入了流控狀態(tài)，此時通過H消息就可以發(fā)送從SRC到SNK的媒體流數(shù)據(jù)包。

在通信過程中的任何狀態(tài)下，都可以通過發(fā)送F消息，進入中止態(tài)，進而回到?jīng)]有連接任何遠程SEP的空閑狀態(tài)。

測試及結(jié)論
該輕型協(xié)議棧的實現(xiàn)與測試，可以基于CSR先進的BlueCore4藍牙芯片來完成。該芯片支持藍牙2.0+EDR規(guī)范，并提供2.1Mb/s的數(shù)據(jù)傳輸速率，比標準藍牙快3倍，可實現(xiàn)更快速的連接，同步支持多個藍牙鏈路，以及音頻流等更寬帶寬的新興應(yīng)用。最上層的音頻應(yīng)用程序?qū)崿F(xiàn)了一個簡單的具有處理SBC格式編解碼信息的播放器，該應(yīng)用程序和部分高層協(xié)議棧通過交叉編譯，下載到硬件平臺主機端。而播放器程序是通過調(diào)用本協(xié)議棧提供的API，進行音頻數(shù)據(jù)流分發(fā)。對于音頻數(shù)據(jù)的接收端SNK，采用摩托羅拉HT820立體聲耳機進行測試，在長時間播放音頻數(shù)據(jù)的情況下，仍然會存在音頻停頓的現(xiàn)象。使用一種截獲空中藍牙信號并進行協(xié)議分析的工具Airsniffer，抓取流媒體傳輸數(shù)據(jù)包，經(jīng)分析，音頻數(shù)據(jù)并未丟失，而是流控機制存在問題，需要進一步完善。