A2DP和AVRCP是傳統(tǒng)藍(lán)牙的兩種高層應(yīng)用協(xié)議。一般來講，在市面的應(yīng)用產(chǎn)品中，支持A2DP的藍(lán)牙產(chǎn)品都有支持AVRCP。

那么，兩者是怎樣配合使用？又各自扮演者什么角色呢？又是分別如何實現(xiàn)的呢？

1）A2DP，Advanced Audio Distribution Profile。規(guī)定了使用藍(lán)牙非同步傳輸信道方式，傳輸高質(zhì)量音頻護(hù)具的協(xié)議棧軟件及使用方法。例如可以使用立體聲藍(lán)牙耳機(jī)來收聽來自音樂播放器的音樂；

2）AVRCP，Audio Video Remote Control Profile。顧名思義，是指遙控功能，定義了控制音頻 視頻流的特征及協(xié)議。一般包括pause，stop，replay，音量控制等遠(yuǎn)程控制操作。例如，使用藍(lán)牙耳機(jī)可以暫停，切換下一曲等操作來控制音樂播放器。

?

1. A2DP的實現(xiàn)

1）A2DP Profile定義了高質(zhì)量音頻數(shù)據(jù)傳輸?shù)膮f(xié)議和過程，包括立體聲和單聲道數(shù)據(jù)的傳輸。這里的高質(zhì)量音頻指的是單聲道(Mono)和立體聲(Sterco)的音頻，主要區(qū)別于藍(lán)牙SCO鏈路上傳輸?shù)钠胀ㄕZ音，當(dāng)然也不包括環(huán)繞聲。

也就是說：A2DP的音質(zhì)與bluetooth audio是有區(qū)別的。Bluetooth audio只能提供voice的音質(zhì)，而A2DP能提供mono或stereo的音質(zhì)。前者傳輸于SCO Channel上，而后者則傳輸于ACL Channel上。

2）A2DP的典型應(yīng)用是將音樂播放器的音頻數(shù)據(jù)發(fā)送到耳機(jī)或音箱。由于藍(lán)牙提供的帶寬較窄，音頻數(shù)據(jù)可能需要進(jìn)行有效的壓縮才能保證接收端的實時播放。

3） A2DP的實現(xiàn)依賴于GAVDP和GAP,在GAVDP中定義了流連接的建立過程，在A2DP中定義流的參數(shù)和編、解碼過程。

?

4）A2DP定義了兩個 role： SRC：音頻數(shù)據(jù)流的源；SNK：音頻數(shù)據(jù)流的接收者。

?

5）A2DP建立在AVDTP傳輸協(xié)議的基礎(chǔ)之上，AVDTP規(guī)定了鏈接是如何建立的，連接建立好之后，音頻數(shù)據(jù)經(jīng)過壓縮之后，便可以收發(fā)了。音頻數(shù)據(jù)是雙向的。

?

PCM碼流，需要很大的帶寬，即低效又費電，不適合無線傳輸。因此需要編碼壓縮之后，再進(jìn)行傳輸。

A2DP要求SRC和SNK至少要支持低于復(fù)雜度自帶編解碼（Low ?Complexity ?Subband Codec，SBC）標(biāo)準(zhǔn)。

MPEG-1 Audio，Mpeg-2 Audio，MPEG-2，4高級音頻編碼（Advanced-4 -http://www.paper.edu.cn Audio Coding,ACC）和自適應(yīng)變換音頻編碼（Adaptive Transform Acoustic Coding，ATRAC）這幾種音頻編碼標(biāo)準(zhǔn)是可選的。

除此之外的其他編碼標(biāo)準(zhǔn)稱為“非A2DP編碼（Non-A2DP Codec），例如CSR家的APTX，FastStream等，注意：

如果SRC端以非A2DP Codec格式發(fā)送流數(shù)據(jù)到SNK,而SNK不支持非A2DP Codec格式的話，SRC會重新以SBC方式編碼再發(fā)送。

?

?

其中，低復(fù)雜度自帶編解碼（SBC）是專門為藍(lán)牙音視頻設(shè)計的，它可以在中等傳碼率下獲得較高的音頻質(zhì)量，并且具有較低的計算復(fù)雜度。

在信令交互的過程中，需要發(fā)現(xiàn)藍(lán)牙設(shè)備的SEP并獲得其服務(wù)能力，如果SEP具有SBC解碼能力，那么需要對SBC有關(guān)參數(shù)進(jìn)行配置，相關(guān)參數(shù)如下：

采樣頻率（48K,44.1K,32K,16K）?

聲道模式（Mono,Dual Channel,Stereo）塊長度（4,8,12,16）

子帶（4,8）

分配方法（SNR、LOUDNES）

BitPool（2~250）

決定傳碼率的編解碼信息包含于SBC數(shù)據(jù)幀頭部，并且和音頻數(shù)據(jù)流一起被不斷的發(fā)送 到SNK

6）limitation：

? ? ?目前A2DP只定義了點對點的音頻傳輸，沒有定義廣播式的音頻傳輸，可能是由于速率的原因。

? ? ?由于射頻信號的傳輸、數(shù)據(jù)流的編、解碼等，在SRC和SNK之間有延遲(例如高通參考設(shè)計設(shè)置為500ms)。?

? ? ?音頻數(shù)據(jù)速率必須小于藍(lán)牙連接的比特率。

?

2. AVDTP--A2DP的基礎(chǔ)協(xié)議

1）概念：

（1）?AVDTP(AUDIO/VIDEO DISTRIBUTION TRANSPORT PROTOCOL)。是用來描述音頻/視頻在藍(lán)牙設(shè)備間的傳輸?shù)膮f(xié)議，是A2DP協(xié)議的基礎(chǔ)協(xié)議，其在協(xié)議棧中的位置如下：
AVDTP協(xié)議建立在connection-oriented L2CAP channel上，只能支持point-to-point signaling。

（2）Stream代表兩個A/V設(shè)備之間流多媒體數(shù)據(jù)的端到端的邏輯連接。

（3）Stream End Point (SEP)：應(yīng)用程序通過這個接口提供Transport Services and AV capabilities來建立Stream。

（4）Stream End Point Identifier (SEID)：標(biāo)識Stream End Point的。

（5）Stream Context (SC)：兩端設(shè)備都有的關(guān)于Stream的信息。

（6）Stream Handle (SH)：主要是暴露給用于程序使用的。

（7）Media Packets, Recovery Packets, and Reporting Packets：根據(jù)三種不同的數(shù)據(jù)類型，有這三種數(shù)據(jù)包。其中，Basic Service會用到Basic service，Report service會用到Reporting Packets，Recovery service會用到Recovery Packets，此外Multiplexing service會用到Media Packets和其余一種或兩種Packet。

（8）Transport Session：一條stream可以分解為多個transport sessions，每個transport session對應(yīng)一個AVDTP的packet category ，which means Media, Recovery, or Reporting packets。?

（9）Transport Session Identifier (TSID)：標(biāo)識Transport Session。

（10）Transport Channel：通常和一個L2CAP Channel對應(yīng)。不用AVDTP Multiplexing Mode時，一條Transport Channel只傳輸一個transport session；用transport session的情況下，一條Transport ?Channel可以傳輸多個 transport session（media,report或者recovery）。
（11）Transport Channel Identifier (TCID)：標(biāo)識Transport Channel，唯一關(guān)聯(lián)一條L2CAP channel。

2）A2DP的連接：

AVDTP連接的建立首先依賴于L2CAP連接的建立，它會在同一條ACL Link上建立兩條L2CAP Channel，一條是用來Signaling，另一條用來進(jìn)行Stream，report和recovery的傳輸。

（1）Signaling的主要過程為：1.DISCOVER 2.GET_CAPABILITIES 3.SET_CONFIGURATION 4.OPEN 5.START。

? ? ? ? ?>1. 首先使用Stream_End_Point_Discover命令發(fā)現(xiàn)ACP中的流端點，主要工作是要去查詢遠(yuǎn)
? ? ? ? ? ? ? ?端的藍(lán)牙設(shè)備（需要遠(yuǎn)端藍(lán)牙設(shè)備的地址，這個地址是唯一的）可以提供的SEP ?，每個SEP
? ? ? ? ? ? ? ?可以提供一些服務(wù)。?

? ? ? ? ? ? ? 遠(yuǎn)端的藍(lán)牙設(shè)備會返回一個respond，respond包含一些信息，最重到是有多少個SEID，媒體服務(wù)類型等信 ? ? ? ? ? ? ? ?息并不十分重要，服務(wù)類型可以通過Get_Capablities來獲得。然后從中選擇將要建立的流端點。發(fā)送 ? ? ? ? ? ? ? ? ? ? ? ? ? Stream_End_Point_Discover命令之后，會獲得很多個SEID，

? ? ? ? ? >2. 然后就要發(fā)送Get_Capabilites命令來獲得每個SEP所能提供的服務(wù)。（一個SEID代表一個SEP）具體的服 ? ? ? ? ? ? ? ?務(wù)類型，以及字段detail 參見AVDTP 的手冊。我們感興趣的是，藍(lán)牙設(shè)備（例如藍(lán)牙頭戴式設(shè)備）是否擁 ? ? ? ? ? ? ? ? ?有SBC解碼的能力，A2DP規(guī)定，藍(lán)牙立體聲耳機(jī)必須支持SBC解碼，其他的解碼方式是可選的，有關(guān)SBC ? ? ? ? ? ? ? ?的內(nèi)容要參見A2DP協(xié)議。
? ? ? ? ? >3. 再使用Set_Configuration命令對流端點進(jìn)行配置，通過Get_Capabilites，可以知道 SEP 可
? ? ? ? ? ? ? ? ?以支持的服務(wù)，然后根據(jù)服務(wù)類型再進(jìn)行一下具體的配置。需要配置音頻的聲道，采樣率等
? ? ? ? ? ? ? ? 信息。當(dāng)然配置的時候，要給出SEID參數(shù)，指明對哪個SEP進(jìn)行配置。

? ? ? ? ? >4. 最后就是啟動流Stream_Start,如果某個SEP 具有Audio Media的服務(wù)，那么打開一個stream，給出SEID參 ? ? ? ? ? ? ? ?數(shù)，stream 是對應(yīng)某個SEP。開啟stream之后，就可以利用write 系統(tǒng)調(diào)用向socket里寫音頻數(shù)據(jù)了，寫的 ? ? ? ? ? ? ?時候不需要再指明具體的SEID。

鏈路建立好之后，就可以進(jìn)行數(shù)據(jù)傳輸，建鏈的過程，屬于AVDTP 協(xié)議的內(nèi)容， 而傳輸?shù)膬?nèi)容要符合A2DP的規(guī)定，當(dāng)然 A2DP 與AVDTP是密不可分的。

?

（2）State Machine如下，共有6個狀態(tài)：IDLE、Configured、OPEN、STREAMING、Closing、Aborting。

其中：
>1. IDLE狀態(tài)指的是流連接沒有建立但L2CAP信道已經(jīng)打開；
>2.?Configured狀態(tài)指SEP的配置完成；?
>3.?OPEN狀態(tài)指流連接已經(jīng)建立；
>4.?STREAMING狀態(tài)指參數(shù)已經(jīng)配置完畢，進(jìn)行流的分發(fā)。
>5.?Closing狀態(tài)指關(guān)閉SEP的狀態(tài)
>6.?Aborting狀態(tài)指Abort流連接?

?

（3）Procedure匯總

Stream End Point Discovery：遠(yuǎn)端設(shè)備提供支持的SEP列表和media Type。
Get All Capabilities：Using the SEID as a reference, the local device can query the service capabilities of the remote SEP。
Stream Configuration：By referencing both the local and the remote SEID, the local device (the INT) configures the SEP of the remote device (the ACP)。
Stream Get Configuration：etrieve the last capabilities settings performed by the remote device on the SEP。
Stream Establishment：The opening of a transport session, while referencing the remote SEID, includes, if necessary, the establishment of a new Transport Channel。
Stream Start：After the Stream Establishment is complete, the Start Streaming procedure causes the streaming to start; i.e., Media (Reporting, Recovery) packets can be exchanged。
Stream Release：initiated by the upper layer within a device; a signal is sent indicating
that a stream end-point be closed.
Stream Suspend：掛起。
Stream Reconfigure：對Stream進(jìn)行配置。
Stream Reconfigure：再次配置。
Security Control：對AV data transmitted over a Bluetooth 提供protection。
Abort：用于兩個設(shè)備的同步。
General Reject：對包含invalid Signal Identifier的Command進(jìn)行的response。
Delay Reporting：provide an initial delay report required for synchronized audio/video playback。

?

結(jié)合（2）和（3）假設(shè)兩個設(shè)備分別為A，B，則狀態(tài)轉(zhuǎn)移簡述：
設(shè)備B的AVDTP處于idle狀態(tài)。
設(shè)備A向設(shè)備B發(fā)送AVDTP_DISCOVER，獲取設(shè)備B的SEP List。
設(shè)備A向設(shè)備B發(fā)送AVDTP_GET_CAPABILITYS，設(shè)備B返回CAPABILITY。
設(shè)備A的upper layer選定SEP后，向設(shè)備B發(fā)送SET CONFIGURATION。如果SEP已被使用，則重新選定SEP并重復(fù)此過程。如果此SEP未被使用，則配置成功。此時AVDTP的狀態(tài)變成configured。
設(shè)備A向設(shè)備B發(fā)送AVDTP_OPEN，設(shè)備B進(jìn)入open狀態(tài)。
設(shè)備A向設(shè)備B發(fā)送AVDTP_START，設(shè)備B進(jìn)入streaming狀態(tài)。設(shè)備B也可發(fā)送同一指令給設(shè)備A，也能進(jìn)入streaming狀態(tài)。
設(shè)備A向設(shè)備B發(fā)送AVDTP_SUSPEND，設(shè)備B進(jìn)入open狀態(tài)。
設(shè)備A向設(shè)備B發(fā)送AVDTP_CLOSE，設(shè)備B進(jìn)入closing狀態(tài)，再轉(zhuǎn)移到idle狀態(tài)。
設(shè)備B處在open狀態(tài)，設(shè)備A向設(shè)備B發(fā)送AVDTP_RECONFIGURE，重新配置成功后，設(shè)備A向設(shè)備B發(fā)送AVDTP_START，設(shè)備B進(jìn)入streaming狀態(tài)

?

（4）Transport Procedures
? ? 分為三種Service：Basic Service，Reporting Service，Recovery Service和Multiplexing Service。
? ? >1. Basic Service只提供signaling 和media streaming。Media Packet Format如下圖：參數(shù)定義如下：

?

>2.?Reporting packet格式如下：
注意：如果不使用multiplexing mode ，一個PDU包含一個meida或者reporting或者recovery packet
每個transport session 使用不同的L2CAP Channel。如果使用Multiplexing Service，則一個transport channel上可能有好幾種transport transport，需要AL header 來進(jìn)行區(qū)分。

（5）signaling message
一個Signal Fragmentation的實例：

Signal command and response headers：

?

參數(shù)Message Type：

?

（6）HCI Log包分析：

>1. 在L2CAP層抓取，分別由Maste和Slave建立了兩條關(guān)于AVDTP的L2CAP連接，并完成了configure的過程，如下：

?

?

我們可以看到AVDTP的主要Signaling的過程：
1.DISCOVER 2.GET_CAPABILITIES 3.SET_CONFIGURATION 4.OPEN 5.START

下面分析一下具體的內(nèi)容：
Frame62：Master->AVDTP_DISCOVER
00000001 00000000?00000110 00000000 00000010 00000000 01000010 00000000 00000000 00000001
前面的是HCI和L2CAP的封裝，這里也順帶看一下吧。
首先是HCI的：
Connection Handle:00000001 00000000 = 0x01 = 1
Broadcast Flag: No broadcast, point-to-point
Packet Boundary Flag: First non-automatically-flushable L2CAP packet
Total Length: 0x06 = 6

L2CAP部分：
PDU Length: 0x02 = 2
Channel ID: 0x0042 ?//注意：這個ID是遠(yuǎn)端Slave的CID

AVDTP部分：
Transaction Label: 0
Packet Type: Single Packet
Message Type: Command
Signaling Identifier: AVDTP_DISCOVER
注：這就是一個Master發(fā)出的Discover command


Frame65：Slave->AVDTP_DISCOVER RESPONSE
00000001 00100000 00001000 00000000 00000100 00000000 01000000 00000000 00000010 00000001 00000100 00000000
HCI和L2CAP簡單看下，主要看AVDTP分部分：
Packet Boundary Flag: First automatically-flushable L2CAP packet
Channel ID: 0x0040 ?//注意：這個ID是本地Master的CID
Message Type: Response Accept
Signaling Identifier: AVDTP_DISCOVER
ACP Stream Endpoint ID: 1
In-use: No
TSEP: SRC
Media Type: Audio ?//由bluetooth分配的bumber
注：具體的resposne結(jié)構(gòu)可以參考AVDTP的Spec。這個主要是遠(yuǎn)端的Slave響應(yīng)本地的AVDTP_DISCOVER command，本地接收的CID為0x40,發(fā)現(xiàn)了遠(yuǎn)端Slave的一個值為1的SEID，而且沒有使用。需要指出的是，packet baoundary flag為 automatically-flushable L2CAP packet，而AVDTP_DISCOVER command中為non-automatically-flushable L2CAP packet。

Frame66 Master->GET_CAPABILITIES
00000001 00000000 00000111 00000000 00000011 00000000 01000010 00000000 00010000 00000010 00000100
看AVDTP的部分：
Transaction Label: 1
Signaling Identifier: AVDTP_GET_CAPABILITIES
ACP Stream Endpoint ID: 1
注：利用DISCOVER中找到的遠(yuǎn)端SEID=1的端口發(fā)送GET_CAPABILITIES來獲取對方信息。

?

>2.?這里先講一下AVDTP的Service是如何描述的。首先分為幾個Service category：

其次，Service是以以下結(jié)構(gòu)來進(jìn)行描述的：

即第一個字節(jié)是所屬的Service category，然后是capability的length，最后是Service capability的information element。

然后繼續(xù)分析：

Frame68：Slave->GET_CAPABILITIES RESPONSE
00000001 00100000 00010000 00000000 00001100 00000000 01000000 00000000 00010010 00000010 00000001 00000000 00000111 00000110 00000000 00000000 00100001 00010101 00000010 00110101
看AVDTP的部分：
Service Category: Media Transport
Length Of Service Capability (LOSC): 0
Service Category: Media Codec
Length Of Service Capability (LOSC): 6
information element部分:參考IETF RFC3550 / RFC1889標(biāo)準(zhǔn)。這里大概的信息是SBC編碼，44100采樣率等。
注：這里獲取的是遠(yuǎn)端SEID的Media Transport和media codec信息。

Frame69：Master->SET_CONFIGURATION
00000001 00000000 00010010 00000000 00001110 00000000 01000010 00000000 00100000 00000011 00000100 00001000 00000001 00000000 00000111 00000110 00000000 00000000 00100001 00010101 00000010 00110101
ACP Stream Endpoint ID: 1
INT Stream Endpoint ID: 2
Service Category: Media Transport
Length Of Service Capability (LOSC): 0
Service Category: Media Codec
Length Of Service Capability (LOSC): 6
注:主要是對遠(yuǎn)端的Slave進(jìn)行configure，貌似沒怎么配置，不和get-capability的一樣嘛。。。

Frame71：Slave->SET_CONFIGURATION RESPONSE
注:遠(yuǎn)端Slave接受了configure

Frame72：Master->OPEN
00000001 00000000 00000111 00000000 00000011 00000000 01000010 00000000 00110000 00000110 00000100
ACP Stream Endpoint ID: 1
注:打開遠(yuǎn)端的SEID=1的端口。

Frame73:Slave->DISCOVER
注：遠(yuǎn)端的Slave向本地的master發(fā)送discover command。Spec上貌似沒有寫是否需要雙向的discover，不過這樣貌似也沒有什么壞處不是嗎

Frame74:Master DISCOVER RESPONSE
00000001 00000000 00001010 00000000 00000110 00000000 01000010 00000000 00000010 00000001 00000100 00000000 00001010 00001000
ACP Stream Endpoint ID: 1?
In-use: No
TSEP: SRC
ACP Stream Endpoint ID: 2
In-use: Yes?
TSEP: SNK?
注：本地的Master有兩個SEID，其中SEID1未使用，可作為SRC，SEID2正在使用，可作為SNK。

Frame76 Slave->OPEN RESPONSE
注:對Frame72的回應(yīng)，接受了本地Master的打開端口的command。

Frame79是遠(yuǎn)端Slave的GET_CAPABLIYY command，本地Master在Frame89回應(yīng)。

Frame88:Master-〉START
注：本地Master開始Stream。

Frame92：Slave->START RESPONSE
注：遠(yuǎn)端Slave接受了START的command，做出resposne。
Frame93：Slave->SUSPEND
注：遠(yuǎn)端Slave掛起本地SEID=2的端口。

Frame94：Master SUSPEND RESPONSE
注：本地接受SEID=2的端口掛起。

Frame134：Master->CLOSE
注：本地UI上手動斷開AVDTP連接，出發(fā)本地MASTER的CLOSE command，關(guān)閉了本地SEID=1的端口。遠(yuǎn)端Slave在Frame138接受了這個命令。

?

?

3. AVRCP：將在A2DP & AVRCP，藍(lán)牙音頻協(xié)議的兄弟組合（2）中總結(jié)。

總結(jié)

以上是生活随笔為你收集整理的A2DP AVRCP，蓝牙音频协议的兄弟组合（1）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。