基于A2DP框架的近距離無(wú)線音頻通信研究
隨著藍(lán)牙技術(shù)在電子產(chǎn)品中的日益普及,藍(lán)牙音頻設(shè)備也層出不窮,其中具有免提功能的藍(lán)牙耳機(jī)和藍(lán)牙音頻網(wǎng)關(guān)的應(yīng)用是最典型的例子。但免提單元與音頻網(wǎng)關(guān)進(jìn)行音頻傳輸建立起來的SCO連接,僅能支持64Kb/s電信級(jí)語(yǔ)音質(zhì)量的音頻流,這也就限制了藍(lán)牙音頻質(zhì)量的提高,同時(shí)也影響了藍(lán)牙的娛樂消費(fèi)市場(chǎng)。為了滿足人們對(duì)高質(zhì)量音頻的需求,進(jìn)一步擴(kuò)大藍(lán)牙產(chǎn)品市場(chǎng),藍(lán)牙特殊興趣小組SIG組織,在藍(lán)牙? 1.1規(guī)范的應(yīng)用框架基礎(chǔ)上又單獨(dú)提出了高級(jí)音頻分發(fā)框架(Advanced Audio Distribution Profile,A2DP)。該框架利用了在L2CAP層建立起來的ACL異步無(wú)連接鏈路來傳輸高質(zhì)量的單聲道或者立體聲音頻數(shù)據(jù),有效負(fù)載的傳輸速率可以達(dá)到300~400Kb/s。
A2DP框架概述
在娛樂消費(fèi)市場(chǎng)中,A2DP實(shí)例化應(yīng)用就是用音樂播放器把音頻數(shù)據(jù)通過ACL連接發(fā)送到耳機(jī)或者音箱上。目前的框架規(guī)范中,并不支持同步的一點(diǎn)對(duì)多點(diǎn)的廣播式音頻分發(fā),而對(duì)于點(diǎn)對(duì)點(diǎn)音頻的分發(fā),又存在著兩種不同的角色,一個(gè)是信源設(shè)備(SRC),這種設(shè)備作為發(fā)起者將數(shù)字音頻流發(fā)送到Piconet網(wǎng)中;另一個(gè)是信宿設(shè)備,是接收信源發(fā)出的音頻流的設(shè)備。如果藍(lán)牙音樂播放器是信源設(shè)備,那么與之交互的藍(lán)牙耳機(jī)就是信宿設(shè)備,信源和信宿的區(qū)別就在于,它是發(fā)起者還是接收者。下面對(duì)該框架所涉及的具體協(xié)議和其依賴框架進(jìn)行分析。
1 A2DP應(yīng)用框架
在典型的藍(lán)牙音頻相關(guān)框架的整體結(jié)構(gòu)中,A2DP框架所處的位置如圖1所示。
服務(wù)發(fā)現(xiàn)應(yīng)用框架(SDAP)所提供的功能,是向其他藍(lán)牙設(shè)備提供自身所具備的服務(wù),并且能夠使用遠(yuǎn)程設(shè)備所提供的服務(wù)和功能。在實(shí)際應(yīng)用中,幾乎所有框架都支持服務(wù)發(fā)現(xiàn)協(xié)議(SDP)。藍(lán)牙音頻視頻遙控應(yīng)用框架(AVRCP)實(shí)現(xiàn)了藍(lán)牙設(shè)備之間的遙控功能,例如,音樂播放器的前進(jìn)、后退、停止、播放等控制信令的傳輸。免提功能頭戴式設(shè)備應(yīng)用框架(HFP/HSP),最主要的應(yīng)用就是實(shí)現(xiàn)了藍(lán)牙耳機(jī)的免提功能和某些藍(lán)牙設(shè)備的音頻網(wǎng)關(guān)功能。
高級(jí)音頻分發(fā)框架(A2DP)依賴于通用音頻視頻分發(fā)框架(GAVDP),GAVDP定義了設(shè)置音頻和視頻流傳輸?shù)牟襟E,而A2DP則進(jìn)一步定義了音頻流傳輸?shù)?a target="_blank">參數(shù)和步驟細(xì)節(jié)。
在實(shí)際應(yīng)用中,邏輯鏈路控制適配層協(xié)議(L2CAP)要求比較高的可靠性,基帶的廣播數(shù)據(jù)分組將被禁止使用,因此,L2CAP層并不支持可靠的多點(diǎn)傳輸信道,這也就是A2DP框架不支持多點(diǎn)廣播式音頻分發(fā)的主要原因之一。而對(duì)于面向高層協(xié)議的開發(fā)和應(yīng)用者,L2CAP層協(xié)議是透明的,因此這里對(duì)A2DP輕型框架具體實(shí)現(xiàn)的相關(guān)描述,也僅限于L2CAP層以上,A2DP相關(guān)的協(xié)議及框架如AVDTP、GAVDP等協(xié)議模塊的設(shè)計(jì)。
圖1 藍(lán)牙音頻框架整體結(jié)構(gòu)
圖1中的藍(lán)牙主機(jī)控制接口HCI層,是協(xié)議棧中軟硬件的接口。這里所涉及的硬件環(huán)境是主機(jī)與主機(jī)控制器連接模型,HCI層以上的協(xié)議(如SDP)在主機(jī)上運(yùn)行,而以下的協(xié)議(如傳輸層的藍(lán)牙基帶協(xié)議等)由藍(lán)牙主機(jī)控制器硬件來完成,這樣既保證了底層協(xié)議傳輸?shù)姆€(wěn)定性,又支持了上層應(yīng)用協(xié)議的可擴(kuò)展性。一旦在市場(chǎng)條件成熟,藍(lán)牙技術(shù)的硬件部分就可以被更快的硬件射頻技術(shù)所取代,高層傳輸協(xié)議經(jīng)過移植仍然可以沿襲使用,大大縮短藍(lán)牙產(chǎn)品的研發(fā)周期。
2 A2DP框架協(xié)議棧
A2DP是音頻傳輸框架,它通過藍(lán)牙傳輸層和對(duì)等設(shè)備,把音頻數(shù)據(jù)流從音頻信源(SRC)到音頻信宿(SNK)進(jìn)行分發(fā),因此該框架所包含的協(xié)議棧也分為兩個(gè)部分,具體表現(xiàn)如圖2所示。
圖2 A2DP框架協(xié)議棧
基帶協(xié)議(Baseband Protocol)、鏈路管理協(xié)議(LMP)、邏輯鏈路控制和適配協(xié)議(L2CAP)及服務(wù)發(fā)現(xiàn)協(xié)議(SDP),在藍(lán)牙核心協(xié)議規(guī)范中都有定義。而藍(lán)牙音頻視頻分發(fā)傳輸協(xié)議AVDTP則定義了藍(lán)牙設(shè)備之間數(shù)據(jù)流句柄的參數(shù)協(xié)商、建立和傳輸過程以及相互交換的信令實(shí)體形式,該協(xié)議是A2DP框架的基礎(chǔ)協(xié)議。
輕型A2DP框架協(xié)議實(shí)現(xiàn)
這里所提出的A2DP框架協(xié)議的實(shí)現(xiàn)集中在音頻信源端,并未設(shè)計(jì)信宿端。之所以定義為輕型的,是因?yàn)樵贏2DP規(guī)范1.0基礎(chǔ)之上,實(shí)現(xiàn)了此規(guī)范所規(guī)定的強(qiáng)制性功能,即在信源端僅僅實(shí)現(xiàn)了高級(jí)音頻分發(fā)的基本功能,如立體聲音頻的傳輸,只支持低復(fù)雜度子帶編解碼(SBC)標(biāo)準(zhǔn),而對(duì)其他編解碼標(biāo)準(zhǔn)并未涉及;在A2DP模塊的實(shí)現(xiàn)中并未包括任何的編解碼能力,這是在用戶層上實(shí)現(xiàn)的,是上層應(yīng)用程序在設(shè)置階段,通過配置協(xié)商來做相應(yīng)的編碼,解碼和音頻內(nèi)容的轉(zhuǎn)換工作;AVDTP模塊的功能不包括校驗(yàn)和報(bào)告,也不包括媒體多路復(fù)用,校驗(yàn)和報(bào)告通道的建立。
1 協(xié)議模塊劃分
A2DP框架協(xié)議劃分了3個(gè)模塊:A2DP模塊、GAVDP模塊和AVDTP模塊,另外還包括測(cè)試協(xié)議棧所需要的Audio應(yīng)用程序測(cè)試模塊。對(duì)于GAVDP,雖然該功能模塊包括音頻/視頻兩種數(shù)據(jù)流的傳輸與分發(fā),但是由于這里側(cè)重對(duì)音頻流進(jìn)行討論,所以視頻流相關(guān)模塊(VDP)并未實(shí)現(xiàn)。圖3是具體實(shí)現(xiàn)模塊劃分圖。
圖3 A2DP框架具體模塊劃分
2 消息傳遞機(jī)制
該輕型框架模塊協(xié)議層之間的交互是通過消息傳遞機(jī)制來實(shí)現(xiàn)的,消息的種類可分為以下4種。
①請(qǐng)求消息REQ
該消息是上層協(xié)議向下層協(xié)議主動(dòng)發(fā)出的請(qǐng)求。
②確認(rèn)消息CFM
上層協(xié)議發(fā)出的每個(gè)REQ消息,都會(huì)收到下層協(xié)議發(fā)上來的確認(rèn)。
③指示消息IND
該消息是下層協(xié)議向上層協(xié)議主動(dòng)發(fā)起的告知。
④響應(yīng)消息REP
對(duì)于每個(gè)下層協(xié)議主動(dòng)發(fā)上來的IND消息,上層協(xié)議都對(duì)此消息進(jìn)行響應(yīng)。
圖4 協(xié)議間的消息傳遞
協(xié)議間的消息傳遞如圖4所示。
采用基于消息傳遞機(jī)制的實(shí)現(xiàn)方法的優(yōu)點(diǎn)如下:
①協(xié)議層之間交互通過固定的消息接口,即使上下層協(xié)議模塊升級(jí),也不會(huì)影響本層協(xié)議模塊的功能,有很好的移植性和可復(fù)用性。
②各層協(xié)議都是異步通信,可以大大降低擁塞情況的發(fā)生。
③協(xié)議棧進(jìn)程可以在上層管理一個(gè)消息隊(duì)列,統(tǒng)一進(jìn)行消息收發(fā),當(dāng)消息向下傳遞過程中遭到拒絕時(shí),可以實(shí)現(xiàn)消息的重傳功能。
④與每層協(xié)議都用一個(gè)單獨(dú)的任務(wù)來實(shí)現(xiàn)相應(yīng)功能相比,采用消息機(jī)制的方法節(jié)省了系統(tǒng)調(diào)度時(shí)間,更具有實(shí)時(shí)性,同時(shí)避免了死鎖的發(fā)生。
3 重要數(shù)據(jù)結(jié)構(gòu)
①消息結(jié)構(gòu)體
消息結(jié)構(gòu)體分為3個(gè)域:發(fā)送模塊Id、接收模塊Id、消息枚舉類型。具體定義如下:
typedef struct
{
?BT_ModuleId sender;
?BT_ModuleId receiver;
?BT_Primitive????? primitive;
} BT_Header;
②流端點(diǎn)結(jié)構(gòu)體
流端點(diǎn)SEP存在于應(yīng)用層中,而應(yīng)用層又在AVDTP中注冊(cè)它的SEP,使其他設(shè)備可以發(fā)現(xiàn)和連接。SEP在3個(gè)模塊—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ù),下面具體分析每個(gè)模塊所實(shí)現(xiàn)功能。
①A2DP模塊
A2DP模塊實(shí)現(xiàn)了通過GAVDP管理SEP和SEP能力的功能,并且在SRC和SNK之間為音頻流文本設(shè)置和配置了流通道。根據(jù)A2DP模塊的通信流程把它的消息接口分為6種類型:流設(shè)置消息,它又可分為對(duì)等流端點(diǎn)發(fā)現(xiàn)和流配置兩個(gè)步驟;流通道釋放消息;開始/掛起流消息;配置/重新配置消息;發(fā)現(xiàn)/得到能力消息;媒體流開始消息。
②GAVDP模塊
GAVDP模塊從多個(gè)使用者角度出發(fā),管理本地流SEP和SEP能力的注冊(cè),處理從遠(yuǎn)程設(shè)備發(fā)來的發(fā)現(xiàn)查詢請(qǐng)求和得到能力請(qǐng)求,同時(shí)基于用戶注冊(cè)的SEP信息,自動(dòng)發(fā)送響應(yīng)。
由于GAVDP模塊的功能是上層A2DP模塊的細(xì)化,因此可以將GAVDP的消息接口和A2DP模塊的接口類型作一致性設(shè)計(jì),兩者消息接口類型基本相同。
③AVDTP模塊
AVDTP模塊負(fù)責(zé)建立一個(gè)到遠(yuǎn)程藍(lán)牙設(shè)備的AVDTP信令通道,并借助于AVDTP協(xié)議發(fā)送所有的信令命令,同時(shí)為媒體流建立傳輸通道,必要的話為校驗(yàn)和報(bào)告也建立通道,另外還支持信令和媒體消息的分段。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)機(jī)如圖5所示。
圖5 SEP在AVDTP模塊中的狀態(tài)機(jī)
整個(gè)通信過程各個(gè)狀態(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ā)出一系列動(dòng)作,包括連接請(qǐng)求、發(fā)現(xiàn)請(qǐng)求和獲取SNK能力請(qǐng)求等。從空閑態(tài)到配置態(tài)的躍遷過程,本協(xié)議棧統(tǒng)稱為流設(shè)置過程。
在打開狀態(tài)下發(fā)送C消息之后,就進(jìn)入了流控狀態(tài),此時(shí)通過H消息就可以發(fā)送從SRC到SNK的媒體流數(shù)據(jù)包。
在通信過程中的任何狀態(tài)下,都可以通過發(fā)送F消息,進(jìn)入中止態(tài),進(jìn)而回到?jīng)]有連接任何遠(yuǎn)程SEP的空閑狀態(tài)。
測(cè)試及結(jié)論
該輕型協(xié)議棧的實(shí)現(xiàn)與測(cè)試,可以基于CSR先進(jìn)的BlueCore4藍(lán)牙芯片來完成。該芯片支持藍(lán)牙2.0+EDR規(guī)范,并提供2.1Mb/s的數(shù)據(jù)傳輸速率,比標(biāo)準(zhǔn)藍(lán)牙快3倍,可實(shí)現(xiàn)更快速的連接,同步支持多個(gè)藍(lán)牙鏈路,以及音頻流等更寬帶寬的新興應(yīng)用。最上層的音頻應(yīng)用程序?qū)崿F(xiàn)了一個(gè)簡(jiǎn)單的具有處理SBC格式編解碼信息的播放器,該應(yīng)用程序和部分高層協(xié)議棧通過交叉編譯,下載到硬件平臺(tái)主機(jī)端。而播放器程序是通過調(diào)用本協(xié)議棧提供的API,進(jìn)行音頻數(shù)據(jù)流分發(fā)。對(duì)于音頻數(shù)據(jù)的接收端SNK,采用摩托羅拉HT820立體聲耳機(jī)進(jìn)行測(cè)試,在長(zhǎng)時(shí)間播放音頻數(shù)據(jù)的情況下,仍然會(huì)存在音頻停頓的現(xiàn)象。使用一種截獲空中藍(lán)牙信號(hào)并進(jìn)行協(xié)議分析的工具Airsniffer,抓取流媒體傳輸數(shù)據(jù)包,經(jīng)分析,音頻數(shù)據(jù)并未丟失,而是流控機(jī)制存在問題,需要進(jìn)一步完善。
評(píng)論
查看更多