蓝牙A2DP协议

转自: 蓝牙音乐之A2DP协议 - 知乎

A2DP Spec下载: Advanced Audio Distribution Profile | Bluetooth® Technology Website

本篇文章简单聊聊蓝牙音乐涉及到的A2DP协议，大家平常使用蓝牙耳机，蓝牙音箱所通过蓝牙声卡播放出来的音乐就是走的A2DP协议实现的，此协议有时被称为媒体音频协议。

1. A2DP

1.1 A2DP协议定义

A2DP： Advance Audio Distribution Profile，高级音频分发协议的缩写。在这里区分下高级音频和蓝牙音频，蓝牙音频一般指的是蓝牙SCO链路上的音频，也就是蓝牙电话，而高级音频指的传输于蓝牙ACL链路上的高质量音频，即为蓝牙音乐的媒体音频。

一个完整的蓝牙音乐不但包含A2DP音频流，还包含AVRCP控制流，AVRCP控制流请看这篇

蓝牙音乐之AVRCP协议 - 知乎

1.2 A2DP协议概况

A2DP协议本质上是一个应用层协议，他也是基于其他协议起作用的，详细的协议依赖关系见下图

A2DP是音频流

VDP是视频流

AVRCP是控制流

A2DP协议核心概况：在蓝牙核心协议的基础上，通过上层A2DP协议将两个蓝牙设备连接到同一个piconet（微微网）中，实现蓝牙音频流的传输功能。

1.3 A2DP协议模型

具体协议模型如下：

A2DP协议规定了两种角色 SRC + SNK

SRC：Source，数字音频流的源，负责将源数据发送到SNK端

SNK：Sink，数字音频流的接收器，负责接收SRC发过来的源数据

这两种角色的扮演者在生活中很是常见，手机蓝牙作为生活中使用最多的设备，不言而喻其主要作为SRC存在，那对应的蓝牙耳机、音箱等设备就作为SNK的角色存在，具体的音频流如下图所示：

音频流从SRC到SNK中间经历的步骤很多，比如MP3、PCM、编码、加密（可选）、数据封装、传输、数据解析、解密（可选）、解码、PCM等等步骤

左侧的SOURCE端作为音频的输入端对音频数据进行编码后，通过两个设备之间建立的ACL链路发送给对方备（sink 端）。在Sink端收到音频数据后，进行解码操作还原出音频完成Audio数据传输。

进行数据传输之前发送端(SRC)与接收端(SNK)需进行一系列信令交互以确认双方传输数据的参数之后才能开始数据传输，其信令交互流程如下：

1.4 编码方式

蓝牙音频传输在当今市面上有如下几种常见的编码方式可供选择

A2DP协议最早规定的基础编码方式也是强制性的编码方式为SBC，我们Android手机一般也都支持SBC编码，AAC是由多家公司共同开发，苹果设备中对AAC有着广泛的支持，aptX类的编码方式的专利权属于高通，而LDAC则是索尼大法在2015年推出的无线音频编码技术，索尼的LDAC、以及LHDC也是众多无线音频编码方式中最为接近无损编码的方式。以上五种编码方式传输的蓝牙音乐音质从低到高排列为：

SBC < AAC < aptX < aptX-HD <LDAC

1.5 A2DP音质和延迟

前面讲到为了在蓝牙通道传输音频数据必须将音频数据进行压缩编码后传输，而这里的压缩和常规认知的文件压缩、解压后得到完全一致的源文件不一样，为了适应蓝牙传输的带宽音频数据被压缩后占用的带宽很小这种压缩为有损压缩。以SBC为例压缩后仅占用200多Kbps 压缩比达到1/7,而这样的有损压缩势必损失音乐的音质。

常见编码器占用带宽如下表。

SBC是A2DP协议强制规定的编码格式。利用人耳对不同频率信号的感知灵敏度不同的特性，在人的听觉（不敏感的部位采用较粗糙的量化，在敏感部位采用较细的量化，以获得更好的主观听觉效果，是音质最差的一种编码器。AAC则是协议规范可选支持的一种高品质编码器，后来实现厂商提出了apt-X,LDAC,LHDC 等高带宽占用的高品质音频编码器，其中LDAC/LHDC更是支持Hi-RES标准认证的96K高解析音频。LC3则是跟随全新一代LE音频发布的LE音频强制支持的高品质低带宽编码技术。总体来说更高的码率意味着更好的音质，然而最新一代LC3的出现则可能打破这一规律，LC3和SBC的主观对比打分如下，在码率为345 kbps的情况下，SBC的分数略高于4.0，但LC3在码率160 kbps情况下即可达到比SBC更高的主观评分。

前面提到蓝牙音频传输必须先进行编码，而编码是按照帧进行的既一定长度的数据进行一次编码压缩，这里累积到足够数据再编码，设备端收到数据再解码播放的过程则会造成延迟。网络上的帖子大多将蓝牙音频延迟归咎于此，其实不然，前文提到的几种编码器编码帧最长的为AAC 一帧长度达到23ms，蓝牙传输一帧的数据也能(通常)在几ms间完成，然而实际延迟却是这个数据的好几倍达到100ms以上，SBC一帧更是只有2ms不到，但其延迟却达到200以上。

实际上影响延迟的主要因素是蓝牙传输的稳定性。理想情况下发送蓝牙音频发送端等时间间距均匀的发送数据包，接收端等时间间距均匀的接收数据，这种情况下接收端可稍微延迟后将收到数据通过喇叭送出，在喇叭播放完这包数据之前可收到下包数据继而能够连续不断的播放，此时蓝牙音频的时延取决于发包间隔和传输时间。

然而现实情况总是不如人意，蓝牙作为一种无线传输协议传输数据可能受到周边无线设备或强电磁设备比如电磁炉、微波炉等设备干扰导致数据出错重传，实际上即使没有干扰由于蓝牙器件本身的性能、或是因为无线传输的特性都是有可能出现传输错误的。传输错误重传导致其中某些包重传次数多传输时间变长，接收端收到的数据包并不是等时间均匀的。这种情况下接收端想要流畅播放必须先缓存一定时间长度的数据之后再进行播放，以防止其中包晚到导致播放不连续，这种情况下真实主要因素是为了抵抗网络传输不稳定性而人为添加的延迟(缓存)，而传输码率越高网络波动带来的影响会更大也就需要更长的延迟来防止卡顿。

总结下来A2DP延迟大有两点原因：1、数据帧到达一定长度才会一次编码压缩。2、错包重传机制导致的延迟

2. AVDTP

从上述的协议模型中可以看出A2DP协议中最关键的就是AVDTP层，在协议中连接起应用层和蓝牙核心协议层之间的交互，接下来就重点分析下AVDTP的相关交互知识点。

A2DP连接过程中涉及到多个AVDTP交互过程，我们已经知道由于蓝牙音乐音频流的单向流动性从而决定了SRC和SNK这两种角色，而AVDTP的交互过程中也涉及到两种角色：INT + ACP，简单理解就是过程的发起者为INT，该过程的接收应答者则是ACP。由于A2DP连接的两个设备在连接之初由于其功能已经被应用层定义好，所以SRC、SNK的角色已被确定，而INT、ACP却是根据过程的启动而定，因此某一个蓝牙设备可能是INT也可能是ACP。

2.1 AVDTP的定义

AVDTP：全称为 AUDIO/VIDEODISTRIBUTION TRANSPORT PROTOCOL，该协议定义了A/V流协商、建立和传输的过程，还指定了在这些设备之间交换的消息格式，以便在A/V分布应用程序中传输它们的音视频流。

1、A2DP协议是基于AVDTP协议的上层协议，A2DP的动作最终都是通过AVDTP实现的。

2、AVDTP协议中关于过程的角色可以简单分为两方：INT（过程发起者）、ACP（过程应答者）

2.2 AVDTP的交互

AVDTP定义了如下这些交互过程：

也定义了如下状态，方便AVDTP的过程交互：

这些状态在交互过程的切换图为：

完整的A2DP连接包含如下几个AVDTP过程：DISCOVER、GET_CAPABILITIES、SET_CONFIGURATION、OPEN

• DISCOVER：发现对端设备内支持的流端点（编码方式编号）
• GET_CAPABILITIES：获取本地设备的所定义的流端点(SEP)的全部能力响应
• SET_CONFIGURATION：设置本次连接的配置（基于本地设备和对端设备双方支持的编码方式,采样频率,通道模式，块长度，子带，分配方法，对端设备发送选取最优的编码方式，采样频率，通道模式，块长度，子带，分配方法的流端点设置给本地设备）
• OPEN：成功配置后，对端设备主动打开音频流端点的命令给本地设备

以上过程全部完成就建立起了AVDTP的信令通道，AVDTP随后也会建立起数据通道。

• 信令通道：控制蓝牙音乐音频流的建立、打开、关闭、暂停等操作
• 数据通道：传输蓝牙音乐数据

下面说下A2DP上的几个应用场景及AVDTP的命令交互状态流程

1、当我们打开音乐播放器时，AVDTP的命令交互和状态流程：

a ）、SINK音箱端ACP会收到SOURCE手机端INT发来的GET_ALL_CAPABILITIES_CMD和SET_CONFIGURATION_CMD命令。AVDTP的状态从IDLE状态切换到CONFIGURED状态

b )、SINK音箱端ACP会收到SOURCE手机端INT发来的OPEN_CMD命令。AVDTP的状态从CONFIGURED状态切换到OPEN，传输过程类型是TRANSPORT_STATE_IDLE

2、当我们播放音乐播放器时，AVDTP的命令交互和状态流程：

a )、SINK音箱端ACP会收到SOURCE手机端INT发来的START_CMD命令。AVDTP的状态从OPEN切换到STREAMING。传输过程类型是TRANSPORT_STATE_ACTIVE

3、当我们暂停音乐播放器时，AVDTP的命令交互和状态流程：

a ) SINK音箱端ACP会收到SOURCE手机端INT发来的SUSPEND_CMD命令。AVDTP的状态从STREAMING切换到OPEN，传输过程类型是TRANSPORT_STATE_IDLE