A2DP全称：Advanced Audio Distribution Profile
AVDTP全称：AUDIO/VIDEO DISTRIBUTION TRANSPORT PROTOCOL
在这里插入图片描述

介绍一下传输流程
source端会由一个播放器提供PCM raw data 数据进行编码压缩，然后通过A2DP，在经过AVDTP,然后走L2CAP，HCI,Teansport,最后到达Controller，然后通过射频发送到 Sink 端的Controller，然后Transport 发送给HCI，经过L2CAP，AVDTP,然后到达A2DP,解码之后重新获取到PCM raw data 就可以通过spk进行播放了

音频概念 PCM raw data:

音频采样率 sample rate： 44.1khz 48khz
位宽 bit width: A2DP 通常是16bit 。用来表示音调的
单声道bps(以 44.1khz举例) 44100 * 16 =705,600
双声道bps(以 44.1khz举例) 44100* 16 * 2 =1,411,200
以双声道来看整个pcm raw data的大小为 1411200/8/1024 = 172kb/s

AVDTP

概念

AVDTP 即 AUDIO/VIDEO DISTRIBUTION TRANSPORT PROTOCOL（音视频分配传输协
议），主要负责 A/V stream 的协商、建立及传输程序，还指定了设备之前传输A/V stream 的消息格式.AVDTP 的传输机制和消息格式是以 RTP 为基础的。 RTP 由 RTP Data Transfer Protocol (RTP)和 RTP Control Protocol(RTCP)组成。 AVDTP 是在 L2CAP 上传输
的。 AVDTP 有专门的 PSM（ 0x19）值。
协议框图
在这里插入图片描述A/V stream 和 A/V signaling 都在 L2CAP 上传输。 Signaling 负责 stream 的发现、配置、建立和传输控制。

AVDTP 一共有以下几个组件
在这里插入图片描述
在这里插入图片描述

  1. Signalling
    命令以及命令响应交互通道
  2. Stream Manager
    流管理组件，一共有以下几种能力：传输流，组合 media 封包，时间戳管理， media
    封包序号管理，报告丢包给上层，抖动计算
  3. Recovery
    封包回复组件
  4. Adaptation Layer
    这层提供了一下几个能力：多路复用模式，允许在一个传输通道(TCID)上多路复
    用多个传输会话(TSID)，使用更强劲头压缩

AVDTP 术语介绍

1.Stream： 两个点对点设备之间的流媒体数据。
2.Source (SRC) and Sink (SNK)： SRC 是音视频的发送方， SNK 是音视频的接收方。
3.Initiator (INT) and Acceptor (ACP)： 启动过程的设备作为启动者、接受启动的设备为接收者。要注意的是 INT 和 ACP 独立于上层应用定义的 SRC 和 SNK，也就是在一个 CMD 跟 RESPONSE 中，发送 CMD 的是 INT 角色，回送 RESPONSE 的就是 ACP 角色，所以他的角色会一直在动态切换中。
4.Application and Transport Service Capabilities： 应用服务和传输服务的功能。应用服务功能比如协商、配置音源设备的 codec，内容保护系统等；传输服务能力比如数据报文的分割和重组，数据包的防丢检测等等。
5.Services, Service Categories, and Service Parameters： AVDTP 的特性集合。ACP 会向 INT 暴露它的 capabilities， INT 启动程序问询 ACP 的 capabilities，并选择一些想用的 capabilities 进行配置。 Application Service Capabilities表示应用层提供的 services，包括：协商和配置 source codecs、内容保护系统、媒体同步等。 Transport Service Capabilities 更具体的描述 services，包括分帧和分段、封装、传输性能报告、包丢失检测、包恢复、稳健的 header 压缩、传输会话到传输通道的多路复用等
6.Media Packets, Recovery Packets, and Reporting Packets： Media Packets 用来封装流媒体数据（可以理解为RTP包），方向是从SRC到SNK。 Recovery packets 包含恢复数据，由SRC发送给SNK（ packet recovery使用时才会有）。 Reporting Packets包含QoS reporting数据（当QoS reporting使用时，可以理解为RTCP包），双向的。
7.Stream End Point (SEP)： 流端点，流端点是为了协商一个流而公开可用传输服务和 A/V 功能的应用程序.
8.Stream Context (SC)： 流上下文。指在流设置过程中，两个对等设备达到一个公共的了解流的配置，包括选择的服务，参数，以及传输通道分配。
9.Stream Handle (SH)： 流句柄。在 SRC 和 SNK 建立了连接之后分配的一个独立的标识符，代表了上层对流的引用
10.Stream End Point Identifier (SEID)： 流端点标识，对特定设备的跨设备引用，该引用用于信令事物
11.Stream End Point State： 流端点状态
12.Transport Session： 传输会话。在 A/V 传输层的内部，在配对的 AVDTP 实体之间，流可以分解为一个、两个或多个三个传输会话。
13.Transport Session Identifier (TSID)： 传输会话标识。代表对一个传输会话的引用。
14.Transport Channel： 传输通道。传输通道指的是对 A/V 传输层下层承载程序的抽象，始终对应 L2CAP 的通道
15.Transport Channel Identifier (TCID)： 传输通道标识。代表对一个传输通道的引用。
16.Reserved for Future Additions（ RFA）： 保留给将来添加
17.Reserved for Future Definitions (RFD)： 保留给将来定义
18.Forbidden (F)： 弃用

AVDTP Signal 封包格式

Signaling 交互流程
在这里插入图片描述
Signal header 封包格式
在这里插入图片描述以上就是 Signal 的 header format,可以看到分 3 种封包格式：

第一个是单一封包
第二个是开始封包，一般用于封包大小>MTU 的拆包的第一个封包
第三个是继续封包和结束封包，一般用于封包大小>MTU 的继续封包和结束封包

参数意义

Transaction Label： 传输标示， 4bit， INT 角色来填写一个值， ACP 必须回送一样的值
Packet Type： 封包类型
在这里插入图片描述
Message Type 消息类型
在这里插入图片描述
Signal Identifier： 信令标识符
在这里插入图片描述
NOSP = Number Of Signal Packets： Start 封包会告知后续有多少个封包要传输
在这里插入图片描述

Stream End Point Discovery

每个 AVDTP 端都会注册一个或者多个 SEP,通过 SEID 来标示，这个命令就是获取对端的 SEP 信息，包括 SEID(SEP 的 ID)， In Use(是否被使用)， MediaType(Audio,Media,MultiMedia在Assigned_Numbers.pdf 获取 ）,TSEP(角色是 Sink 还是 Source)

Stream End Point Discovery Command

获取到 remote 端所有的 SEP 的信息 ，封包格式 两个Byte组成：
在这里插入图片描述

第1个byte: 就是Signaling header 的第一个字节 见上一段
第2个byte： 前6个字节是 AVDTP_DISCOVER-0x01 上方的表格的有给出值

Stream End Point Discovery Response

是对 AVDTP_DISCOVER_CMD 的回应。Payload 中带有所有 SEP的信息封包格式 ：
在这里插入图片描述

第1个byte： 就是Signaling header 的第一个字节 见上一段
第2个byte： 前6个字节是 AVDTP_DISCOVER-0x01
第3个byte：第一位是保留位，第二位是 In Use表示这个SEP是否被使用，后6位表示 ACP SEID，可用值是 0x1~0x3e
第4个byte: 前三位是保留位，第四位TSEP 表示是SNK还是SRC,0=SRC，1=SNK，后四位表示 media Type 见下图
在这里插入图片描述
第三，四个byte就是ACP Endpoint的详细信息，如果有多个，那么也得占2个byte跟三四的格式是一样的。

Stream End Point Discovery Reject

对端拒接SEP的discovery封包格式 ：
在这里插入图片描述

前两个byte已经介绍过了
第三个byte 是error code
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

下面来看一个BTsnoop对照着分析一下
在这里插入图片描述

从这边我们可以看出来我们的数据是 00 01 我们转成二进制就是
0000 0000
0000 0001
从第一个byte我们可以看出来，Transaction Label是0，Packet type 00 表示的是单包，message type 00 表示是command
从第二个byte00 0001 表示 AVDTP_DISCOVER

然后我们看看回包
在这里插入图片描述

我们可以看到包的数据是 02 01 04 08 08 08
1.首先我们看看 02 01 这组 Signal header的 意义
0000 0010 0000 0001 从第一个byte可以看出来是一个单包的 Response Accept，第二个byte表示是对 AVDTP_DISCOVER的回复
2.然后就是SEP 信息 04 08 了
0000 0100 0000 1000 ACP SEID 是1 这个sep没有被使用，media type 是video，TSEP是SRC
3.然后是第二个 SEP信息 08 08
0000 1000 0000 1000 ACP SEID 是2 这个sep没有被使用，media type 是video，TSEP是SRC

Get All Capabilities/Get Capabilities

获取SRC 支持的特性 Get All Capabilities和Get Capabilities封包格式是一样的 但是最新的协议规定一定要使用 Get All Capabilities，所以这边只用Get All Capabilities 进行介绍

Get All Capabilities Command：

在这里插入图片描述

Get All Capabilities 和 Get Capabilities 只有Signal Identifier的不同，也就是第二个byte 的前6bit有不同， 具体的值在signal 封包里面已经有介绍了
第3个byte 的ACP SEID，在SEP discover的时候已经获取的到，这边的传入ACP SEID就是我们要具体获取那个SEID的特性

Get All Capabilities Response：

在这里插入图片描述

前两个byte不过多赘述了已经讲过好几次了
第三个byte开始就是 具体的特性
每一个Capabilities 都是一个TLV的结构 Service Category 就是代表了type,Length Of Service Capabilities (LOSC)表示value的长度，Service Capabilities Information Elements也就是value 可以有多个Capabilities 但每个Capabilities 都是遵守这个格式的。
在这里插入图片描述
Service Category 有下面几个值
在这里插入图片描述
Service Capabilities Information Elements 特性的具体值表现
1.Media Transport Capabilities(媒体传输能力)
在这里插入图片描述
2.Reporting Capabilities
在这里插入图片描述
3.Recovery Capabilities(支持恢复服务的ACP设备应公开以下传输功能)
在这里插入图片描述
4.Media Codec Capabilities(媒体编解码特性)
在这里插入图片描述
Media Type 在 Assigned_Numbers.pdf 中有定义
在这里插入图片描述
Media Codec Type 在 Assigned_Numbers.pdf 中有定义
在这里插入图片描述
Media Codec Specific Information Elements 是具体的 media codec的信息，在A2DP spec中有介绍，太多了这边就不展开，可以直接去下载spec查看
5.Content Protection Capabilities 内容保护相关的东西，具体的在AVDTP spec 第四章查看在这里插入图片描述
6.Header Compression Capabilities
在这里插入图片描述
7.Multiplexing Capabilities
在这里插入图片描述
8.Delay Reporting Capabilities
在这里插入图片描述

Get All Capabilities Reject：

在这里插入图片描述

BTSNOOP 分析及 media codec SBC封包

下面我们看一份具体的btsnoop加深一下印象
这一份btsnoop Ellisys 自带的，不需要额外去录
在这里插入图片描述
SNK发起Get Capabilities cmd
在这里插入图片描述

Header 部分已经介绍过了很多次了，这边不做赘述了
ACP SEID 是04 是因为 SEID占后6bit 前两个bit是预留位不使用 0000 0100 也就是0x04,而这个SEID的值已经在 discover的时候获取到了

接下来SRC就会回复 具体的Capabilities 过来

在这里插入图片描述

signal Header 不做介绍了，直接看proload 数据
1)Header 之后 跟着的第一个byte 是 01 表示 Service Categor 通过上面的表格我们可以知道这个Type是 Media Transport，之后length是00 表示没有value了。我们在Media Transport 的封包格式里面也可以知道这一点。
2)然后我们就知道第一个 Capabilities 已经结束了，下面就是第二个 Capabilities 了。 07我们去查表可以知道这个type表示的media codec 之后的length是0x06 也就是value占了 6个byte。value的第一个byte是 media type是00 我们同样在上面有介绍过这个值，之后的Media Codec Type 00 表示使用的SBC 编解码方式 这部分内容在A2DP spec 4.3中查看
再然后的内容是 media codec elements 是 FF FF 02 2D 转二进制如下
1111 1111 1111 1111 0000 0010 0010 1101，下图表示 每一位表示的意义
在这里插入图片描述
Sampling Frequency（采样率）SRC至少要支持44.1khz和48khz中的一种，SNK则是44.1khz和48khz都要支持。 element 第一个byte的后四个字节，我们从btsnoop 中看到这四个字节是1111 表示这四个采样率 SRC都支持。
在这里插入图片描述
Channel Mode（声道选择）SRC单声道必须要支持，其他的至少需要支持一种。SNK则是全部都要支持。 element 第一个byte的前四个字节，我们从btsnoop 中看到这四个字节是1111 表示这四个声道SRC都支持。
MONO：单声道
DUAL CHANNEL：双声道
STEREO：立体声
JOINT STEREO：联合立体声
在这里插入图片描述
Block Length（块长度）SRC和SNK都必须全部支持。从btsnoop也可以看出来这四位是 1111
在这里插入图片描述
Subbands（次频带）SRC必须支持4哥次频带，SNK 两个都要支持。从btsnoop也可以看出来这两位位是 11 表示都支持。
在这里插入图片描述
Allocation Method：配置方法 从btsnoop也可以看出来这两位位是 11 表示都支持。
在这里插入图片描述
最后的两个byte是Minimum / Maximum Bitpool Value。 从btsnoop可以看出来 min bitpool是2 max bitpool 是45。
bitpool在播放设备中可以设置 SBC 编码质量 大概 1 bitpool = 6～7 kbit/s。 SBC 是一种复杂度较低的编码格式，同等码率下音质稍差，根据这个网站上的比较，最高 328 kbit/s 的 SBC 音质大约介于 224 kbit/s 到 256kbit/s 的 MP3 之间。此外，设置不当、信号差、设备不支持高 bitpool 等都会造成传输码率下降而使音质下降，耳机或音箱本身的音质也是很重要的因素。下面是不同Bitpool对应的码率
在这里插入图片描述
3)第三个 Capability，我们可以看出来type是04表示Content Protection Capabilities(内容保护)。length是02 表示只有两个value ，CP_TYPE_LSB = 2 CP_TYPE_MSB = 0。

Stream Configuration

INT选择所需的SEP 及其服务能力，用于向ACP发送/接收A/V流。INT 通过使用AVDTP_SET_CONFIGURATION_CMD将选定的SEP及其服务能力通知给ACP。AVDTP_SET_CONFIGURATION_CMD 表示SEP所需的所有服务能力。

Set Configuration Command

在这里插入图片描述

ACP SEID 就是我们获取的到SEID
INT SEID 也是
Capability 的配置就是按照我们上面获取到 内容来按位配置通知SRC就行

Set Configuration Response

接受了这个配置

在这里插入图片描述

Set Configuration Reject

拒绝了这个配置，比方说我们配置了一个SRC不支持的采样率就会回复这个。
在这里插入图片描述

BTSNOOP 分析

这是一个配置的BTSNOOP，可以按位去查看一下配置项。
在这里插入图片描述

Get Stream configuration

获取配置信息

Get Configuration Command

在这里插入图片描述

Get Configuration Response

在这里插入图片描述

第三个byte就会回复的就是你配置信息

Get Configuration Reject

在这里插入图片描述

Stream Reconfigure

再次设置SEP 配置

Reconfigure Command

在这里插入图片描述

Reconfigure Response

在这里插入图片描述

Reconfigure Reject

在这里插入图片描述

Stream Establishment

建立流端点信号

Open Stream Command

在这里插入图片描述

Open Stream Response

在这里插入图片描述

Open Stream Reject

在这里插入图片描述

Stream Star

启动stream 有ACP发起 INT接收，当src启动了音乐播放器就是发出这个命令，如果是SNK去发起这个命令并不会有什么作用。蓝牙端设备如果要启动音乐要使用AVRCP start 命令才能播放音乐，然后src 会发出这个命令来通知snk我在播放音乐了

Start Stream Command

在这里插入图片描述

这边是可以连接多个SEID的不过通常是只使用一个

Start Stream Response

在这里插入图片描述

Start Stream Reject

在这里插入图片描述

Stream Release

关闭流断点

Close Stream Command

在这里插入图片描述

Close Stream Response

在这里插入图片描述

Close Stream Reject

在这里插入图片描述

Stream Suspend

挂起流端点

Suspend Command

在这里插入图片描述

可以同时挂起多个SEP

Suspend Response

在这里插入图片描述

Suspend Reject

在这里插入图片描述

如果是reject 会把 reject 的SEID也给到回复回来

Abort

在流建立过程中，如果任何一个设备不再想继续，使用 AVDTP_ABORT_CMD。该命令表示流建立 中止。

Abort Command

在这里插入图片描述

Abort Response

在这里插入图片描述

Security Control

Security Control Command

在这里插入图片描述

Security Control Response

在这里插入图片描述

Security Control Reject

在这里插入图片描述

General Reject

ACP使用一般拒绝消息来响应 包含无效信号标识符的命令消息。消息类型应设置为一般拒绝

在这里插入图片描述

Delay Report

延迟报告命令用来向SRC 设备报告SNK设备的延迟值。这样可以同步播放音频和视频。延迟报告通过 从SNK发送到SRC。因此，SNK始终是延迟报告过程 的INT，而SRC始终是ACP。这与其他信令命令 相反，其中INT/ACP角色独立于SRC/SNK角色。
延迟值由一个以1/10毫秒为单位的两字节值
在这里插入图片描述

当我们的设置 MSB = 13 LSB = 88 也就是 5000，说明我们delay时间是500ms

AVDTP media 封包格式

浅灰色部分是必需要内容，也就是画红框的这一部分内容。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

1.Version:RTP 版本，一般值是 2，还有两个值但是一般不用，值为 1 就是 RTP 的草案版本值为 0 是在最开始的” vat” 音频工具中使用
2.Padding:在包末尾填充 1 个或者多个 byte 表示填充，这部分忽略
3.Extension： 扩展位，此位如果是 1，那么在固定头部后面加一个 byte 扩展位
4.CSRC count： 标示后面的 CSRC 有多少 Byte
5.Marker (M):marke 是由一个 profile 定义 的。用来 允许 标识在 像报文流 中界定 帧界 等的 事件。一个 profile 可能定义了附加 的标识位或者通过修改 payload type域中的位数量来指定没有标识位。
6.Payload Type (PT)： 有效荷载类型，占 7 位，用于说明 RTP 报文中有效载荷的类型，如 GSM 音频、 JPEM 图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。
7.Sequence Number： 占 16 位，用于标识发送者所发送的 RTP 报文的序列号，每发送一个报文，序列号增 1。这个字段当下层的承载协议用 UDP 的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的 sequence 是分别记数的。
7.Time Stamp： 时间戳 实际上，时间戳增加一并不是我们通常意义上的过了一个微秒，而是增加了一个采样间隔那么长的时间。 Time Stamp = Time Stamp + N*本帧采样点数，本帧采样点数 = 子带数（subbands） × 块数（blocks）。
8.SSRC： 占 32 位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的 SSRC。
9.CSRC list： 每个 CSRC 标识符占 32 位，可以有 0～15 个。每个 CSRC 标识了包含在该 RTP 报文有效载荷中的所有特约信源
后续的 Media payload 就是音频数据了

在这里插入图片描述
在这里插入图片描述

这边是一个具体的BTsnoop

80 60 00 01 00 00 00 00 00 00 00 00
1.第一个byte 80->1000 0000 version：10 padding:0 Extension:0 CSRC count:0000
2,第二个byte 60->01100000 marker：0 Payload Type (PT)：1100000
3.第三 四个byte 00 01 ->00000001 表示第一包，从第二张图可以看到编程00 02 了就是表示第二包了
4.4byte的time stamp 从第一包我们可以看出来 传了6个frame 所以我们认真第二包 time stamp 是128*6 = 768,从第二张图可以看到我们算的没错。
5.SSRC 0x00000000、
6.media payload的解析在A2DP的文档去看
在这里插入图片描述

在这里插入图片描述

A2DP

数据交互图
在这里插入图片描述

1） A2DP source 的发送流程UL 收集到 PCM 数据，然后发送到 A2DP， A2DP 经过 codec PCM lib(SBC,MPEG-1,2 AudioMPEG-2, 4 AACATRAC family 或者自定义 encoder pcm lib)压缩成特定的音频格式，然后交给 AVDTP， AVDTP 转交给 L2CAP,L2CAP 通过 ACL 格式转交给 HCI，然后到达 BT chip，通过 RF 射频出去。
2） A2DP sink 的接收流程BT chip 通过 RF 接收进来数据，然后通过 ACL 交给 HCI，然后交给 L2CAP,L2CAP交给 AVDTP， AVDTP 交给 A2DP， A2DP 收到的是remote 经过压缩的数据，此时通过 codec pcm lib(SBC,MPEG-1,2 AudioMPEG-2, 4 AACATRAC family 或者自定义encoder pcm lib)解压成 PCM 数据，然后交于声卡播放

Audio codec

在这里插入图片描述
在这里插入图片描述

所有设备强制规定必须有 SBC 的 codec 算法
SBC codec 解析在本章 Set Configuration Command 里面有介绍。

SDP

A2DP Source 的 SDP
在这里插入图片描述
A2DP Sink 的 SDP
在这里插入图片描述

Logo
智能体开发者社区

中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。

更多推荐

MCP协议开发实战：从零搭建AI Agent工具链

创建静态资源（如项目 README 文件）。创建动态资源（如实时系统状态）。在 Client 中请求并利用资源上下文。回顾 MCP 协议如何降低 AI Agent 开发门槛。当前生态的局限与未来的演进方向。鼓励读者基于此大纲进行实践，并参与开源贡献。

avatar 智能体开发者社区

AI Agent可观测性：破解多步推理黑盒

随着AI Agent在复杂任务中承担越来越多的决策角色，其内部的多步推理过程往往如同一个“黑盒”，难以理解、调试和信任。本文旨在探讨AI Agent可观测性（Observability）的核心概念、技术挑战与实践方案，为开发者提供一套系统的方法论和工具链，以“照亮”Agent的推理黑盒，实现对其行为、决策逻辑与内部状态的全面洞察。构建AI Agent的可观测性体系不再是“锦上添花”，而是保障其在大

avatar 智能体开发者社区

MCP协议开发实战：从零搭建AI Agent工具链

回顾：我们从协议概念到动手搭建了一个可用的MCP工具链。MCP的生态现状：官方与社区提供的Server示例（GitHub, Jira, Notion等）。未来方向：更复杂的工具编排、多模型协作、可视化工具开发平台。鼓励动手：鼓励读者基于此框架，开发解决自己实际问题的工具。

avatar 智能体开发者社区