|
隨著藍(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電信級語音質(zhì)量的音頻流，這也就限制了藍(lán)牙音頻質(zhì)量的提高，同時(shí)也影響了藍(lán)牙的娛樂消費(fèi)市場。為了滿足人們對高質(zhì)量音頻的需求，進(jìn)一步擴(kuò)大藍(lán)牙產(chǎn)品市場，藍(lán)牙特殊興趣小組SIG組織，在藍(lán)牙 1.1規(guī)范的應(yīng)用框架基礎(chǔ)上又單獨(dú)提出了高級音頻分發(fā)框架（Advanced Audio DistributionProfile，A2DP）。該框架利用了在L2CAP層建立起來的ACL異步無連接鏈路來傳輸高質(zhì)量的單聲道或者立體聲音頻數(shù)據(jù)，有效負(fù)載的傳輸速率可以達(dá)到300～400Kb/s。 A2DP框架概述 在娛樂消費(fèi)市場中，A2DP實(shí)例化應(yīng)用就是用音樂播放器把音頻數(shù)據(jù)通過ACL連接發(fā)送到耳機(jī)或者音箱上。目前的框架規(guī)范中，并不支持同步的一點(diǎn)對多點(diǎn)的廣播式音頻分發(fā)，而對于點(diǎn)對點(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ā)起者還是接收者。下面對該框架所涉及的具體協(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)功能。 高級音頻分發(fā)框架（A2DP）依賴于通用音頻視頻分發(fā)框架（GAVDP），GAVDP定義了設(shè)置音頻和視頻流傳輸?shù)牟襟E，而A2DP則進(jìn)一步定義了音頻流傳輸?shù)膮?shù)和步驟細(xì)節(jié)。 在實(shí)際應(yīng)用中，邏輯鏈路控制適配層協(xié)議（L2CAP）要求比較高的可靠性，基帶的廣播數(shù)據(jù)分組將被禁止使用，因此，L2CAP層并不支持可靠的多點(diǎn)傳輸信道，這也就是A2DP框架不支持多點(diǎn)廣播式音頻分發(fā)的主要原因之一。而對于面向高層協(xié)議的開發(fā)和應(yīng)用者，L2CAP層協(xié)議是透明的，因此這里對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ò)展性。一旦在市場條件成熟，藍(lán)牙技術(shù)的硬件部分就可以被更快的硬件射頻技術(shù)所取代，高層傳輸協(xié)議經(jīng)過移植仍然可以沿襲使用，大大縮短藍(lán)牙產(chǎn)品的研發(fā)周期。 2 A2DP框架協(xié)議棧 A2DP是音頻傳輸框架，它通過藍(lán)牙傳輸層和對等設(shè)備，把音頻數(shù)據(jù)流從音頻信源（SRC）到音頻信宿（SNK）進(jìn)行分發(fā)，因此該框架所包含的協(xié)議棧也分為兩個(gè)部分，具體表現(xiàn)如圖2所示。 圖2 A2DP框架協(xié)議棧 基帶協(xié)議（BasebandProtocol）、鏈路管理協(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)了高級音頻分發(fā)的基本功能，如立體聲音頻的傳輸，只支持低復(fù)雜度子帶編解碼（SBC）標(biāo)準(zhǔn)，而對其他編解碼標(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模塊，另外還包括測試協(xié)議棧所需要的Audio應(yīng)用程序測試模塊。對于GAVDP，雖然該功能模塊包括音頻/視頻兩種數(shù)據(jù)流的傳輸與分發(fā)，但是由于這里側(cè)重對音頻流進(jìn)行討論，所以視頻流相關(guān)模塊（VDP）并未實(shí)現(xiàn)。圖3是具體實(shí)現(xiàn)模塊劃分圖。 圖3 A2DP框架具體模塊劃分 2 消息傳遞機(jī)制 該輕型框架模塊協(xié)議層之間的交互是通過消息傳遞機(jī)制來實(shí)現(xiàn)的，消息的種類可分為以下4種。 ①請求消息REQ 該消息是上層協(xié)議向下層協(xié)議主動(dòng)發(fā)出的請求。 ②確認(rèn)消息CFM 上層協(xié)議發(fā)出的每個(gè)REQ消息，都會(huì)收到下層協(xié)議發(fā)上來的確認(rèn)。 ③指示消息IND 該消息是下層協(xié)議向上層協(xié)議主動(dòng)發(fā)起的告知。 ④響應(yīng)消息REP 對于每個(gè)下層協(xié)議主動(dòng)發(fā)上來的IND消息，上層協(xié)議都對此消息進(jìn)行響應(yīng)。 圖4 協(xié)議間的消息傳遞 協(xié)議間的消息傳遞如圖4所示。 采用基于消息傳遞機(jī)制的實(shí)現(xiàn)方法的優(yōu)點(diǎn)如下： ①協(xié)議層之間交互通過固定的消息接口，即使上下層協(xié)議模塊升級，也不會(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中注冊它的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è)置消息，它又可分為對等流端點(diǎn)發(fā)現(xiàn)和流配置兩個(gè)步驟；流通道釋放消息；開始/掛起流消息；配置/重新配置消息；發(fā)現(xiàn)/得到能力消息；媒體流開始消息。 ②GAVDP模塊 GAVDP模塊從多個(gè)使用者角度出發(fā)，管理本地流SEP和SEP能力的注冊，處理從遠(yuǎn)程設(shè)備發(fā)來的發(fā)現(xiàn)查詢請求和得到能力請求，同時(shí)基于用戶注冊的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)作，包括連接請求、發(fā)現(xiàn)請求和獲取SNK能力請求等。從空閑態(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)。 測試及結(jié)論 該輕型協(xié)議棧的實(shí)現(xiàn)與測試，可以基于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è)簡單的具有處理SBC格式編解碼信息的播放器，該應(yīng)用程序和部分高層協(xié)議棧通過交叉編譯，下載到硬件平臺主機(jī)端。而播放器程序是通過調(diào)用本協(xié)議棧提供的API，進(jìn)行音頻數(shù)據(jù)流分發(fā)。對于音頻數(shù)據(jù)的接收端SNK，采用摩托羅拉HT820立體聲耳機(jī)進(jìn)行測試，在長時(shí)間播放音頻數(shù)據(jù)的情況下，仍然會(huì)存在音頻停頓的現(xiàn)象。使用一種截獲空中藍(lán)牙信號并進(jìn)行協(xié)議分析的工具Airsniffer，抓取流媒體傳輸數(shù)據(jù)包，經(jīng)分析，音頻數(shù)據(jù)并未丟失，而是流控機(jī)制存在問題，需要進(jìn)一步完善。 |
