A2DP和AVRCP是傳統藍牙的兩種高層應用協議。一般來講，在市面的應用產品中，支持A2DP的藍牙產品都有支持AVRCP。

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

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

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

?

1. A2DP的實現

1）A2DP Profile定義了高質量音頻數據傳輸的協議和過程，包括立體聲和單聲道數據的傳輸。這里的高質量音頻指的是單聲道(Mono)和立體聲(Sterco)的音頻，主要區別于藍牙SCO鏈路上傳輸的普通語音，當然也不包括環繞聲。

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

2）A2DP的典型應用是將音樂播放器的音頻數據發送到耳機或音箱。由于藍牙提供的帶寬較窄，音頻數據可能需要進行有效的壓縮才能保證接收端的實時播放。

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

?

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

?

5）A2DP建立在AVDTP傳輸協議的基礎之上，AVDTP規定了鏈接是如何建立的，連接建立好之后，音頻數據經過壓縮之后，便可以收發了。音頻數據是雙向的。

?

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

A2DP要求SRC和SNK至少要支持低于復雜度自帶編解碼（Low ?Complexity ?Subband Codec，SBC）標準。

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

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

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

?

?

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

在信令交互的過程中，需要發現藍牙設備的SEP并獲得其服務能力，如果SEP具有SBC解碼能力，那么需要對SBC有關參數進行配置，相關參數如下：

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

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

子帶（4,8）

分配方法（SNR、LOUDNES）

BitPool（2~250）

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

6）limitation：

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

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

? ? ?音頻數據速率必須小于藍牙連接的比特率。

?

2. AVDTP--A2DP的基礎協議

1）概念：

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

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

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

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

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

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

（7）Media Packets, Recovery Packets, and Reporting Packets：根據三種不同的數據類型，有這三種數據包。其中，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對應一個AVDTP的packet category ，which means Media, Recovery, or Reporting packets。?

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

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

2）A2DP的連接：

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

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

? ? ? ? ?>1. 首先使用Stream_End_Point_Discover命令發現ACP中的流端點，主要工作是要去查詢遠
? ? ? ? ? ? ? ?端的藍牙設備（需要遠端藍牙設備的地址，這個地址是唯一的）可以提供的SEP ?，每個SEP
? ? ? ? ? ? ? ?可以提供一些服務。?

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

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

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

鏈路建立好之后，就可以進行數據傳輸，建鏈的過程，屬于AVDTP 協議的內容， 而傳輸的內容要符合A2DP的規定，當然 A2DP 與AVDTP是密不可分的。

?

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

其中：
>1. IDLE狀態指的是流連接沒有建立但L2CAP信道已經打開；
>2.?Configured狀態指SEP的配置完成；?
>3.?OPEN狀態指流連接已經建立；
>4.?STREAMING狀態指參數已經配置完畢，進行流的分發。
>5.?Closing狀態指關閉SEP的狀態
>6.?Aborting狀態指Abort流連接?

?

（3）Procedure匯總

Stream End Point Discovery：遠端設備提供支持的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進行配置。
Stream Reconfigure：再次配置。
Security Control：對AV data transmitted over a Bluetooth 提供protection。
Abort：用于兩個設備的同步。
General Reject：對包含invalid Signal Identifier的Command進行的response。
Delay Reporting：provide an initial delay report required for synchronized audio/video playback。

?

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

?

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

?

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

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

Signal command and response headers：

?

參數Message Type：

?

（6）HCI Log包分析：

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

?

?

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

下面分析一下具體的內容：
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是遠端Slave的CID

AVDTP部分：
Transaction Label: 0
Packet Type: Single Packet
Message Type: Command
Signaling Identifier: AVDTP_DISCOVER
注：這就是一個Master發出的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結構可以參考AVDTP的Spec。這個主要是遠端的Slave響應本地的AVDTP_DISCOVER command，本地接收的CID為0x40,發現了遠端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中找到的遠端SEID=1的端口發送GET_CAPABILITIES來獲取對方信息。

?

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

其次，Service是以以下結構來進行描述的：

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

然后繼續分析：

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標準。這里大概的信息是SBC編碼，44100采樣率等。
注：這里獲取的是遠端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
注:主要是對遠端的Slave進行configure，貌似沒怎么配置，不和get-capability的一樣嘛。。。

Frame71：Slave->SET_CONFIGURATION RESPONSE
注:遠端Slave接受了configure

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

Frame73:Slave->DISCOVER
注：遠端的Slave向本地的master發送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的回應，接受了本地Master的打開端口的command。

Frame79是遠端Slave的GET_CAPABLIYY command，本地Master在Frame89回應。

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

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

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

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

?

?

3. AVRCP：將在A2DP & AVRCP，藍牙音頻協議的兄弟組合（2）中總結。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。