在无线音频的世界里，一场静默却深刻的革命正在进行。

它，就是LE Audio。

这不仅仅是一次技术迭代，而是从底层重新定义声音如何被创造、传输和体验的范式转移。其复杂性令人敬畏——它并非单一技术，而是一套精密的生态系统：全新的LC3编解码器以超凡效率重塑音质与功耗的平衡，多重串流音频让真无线立体声达到前所未有的稳定与同步，而音频广播功能则打破了“一对一”连接的百年窠臼，让声音如电台般自由播撒。

然而，正是这种复杂性，构成了我们必须深入学习它的不可辩驳的理由。未来的声音图景将由它绘制：从下一代真无线耳机、无障碍助听设备到公共场所的沉浸式音频导览、多语言广播，乃至元宇宙中清晰无缝的语音交互。不了解LE Audio，将意味着在即将到来的音频浪潮中失去对话的基石。

这不仅仅关乎技术本身，更关乎我们如何连接彼此，如何感知世界。让我们共同开启这段探索之旅，揭开LE Audio的复杂面纱，看清它为何必将成为未来数年里，每一个科技从业者、音频爱好者乃至普通用户都无法忽视的关键命题。

接下来的系列文章，我们将逐步拆解这座精妙的技术大厦。

同时我也录制了一系列的Le audio视频，有兴趣的可以咨询，我会带领你们入门Le audio！翻过大山，眼下皆是风景！！！

------------------------------------------------------------------------------------------------------------------------------------------

视频链接：https://item.taobao.com/item.htm?id=1001969040805&mi_id=000032T4qZX9WZoRwX6YbxlNUaZOfOI6XoxDx0jxsfnwlEc&spm=a21xtw.29178619.0.0

Le Audio文章目录：

https://wlink.blog.csdn.net/article/details/158457264?spm=1001.2014.3001.5502

---------------------------------------------------------------------------------------------------------------------------------

本文力争给大家讲明白几个核心点：

• ASCS config Qos的作用是什么？
• ASCS config Qos的流程是什么？

带着这两个疑问我们就开始文本的介绍！

一. Config Qos的作用

Config QoS 操作可以看作是 LE 音频（LE Audio） 流程中的“铺设数据快车道”环节。它主要负责告诉音频接收设备，数据将以怎样的方式、在多长时间内送达，从而为高质量的音频传输奠定基础。这个操作通常在“Codec 配置”完成之后进行，是连接配置与音频播放的关键一步-。

Config Codec vs. Config QoS：Config Codec 负责“选什么，怎么编码”，而 Config QoS 负责“怎么传，传多快”。在 Config Codec 完成后，客户端会发起 Config QoS 来配置链路层参数-。

📡 Config QoS 有何用？

可以将Config QoS理解为配置音频“物流”的规则，它的核心作用包括：

• 协商传输质量 (QoS)：单播客户端与服务器共同协商并确立一套传输质量参数，为即将到来的音频数据流划分出专用的“快车道”，确保数据传输的稳定与高效https://wlink.blog.csdn.net/article/details/158457264?spm=1001.2014.3001.5502。
• 确定传输时机：详细规定了数据发送和接收的精确时间节奏，例如发送数据包的间隔（SDU_Interval）、每个数据包的大小（SDU_Size）以及服务器处理并播放音频的延迟时间（Presentation_Delay）。
• 保障传输可靠性：通过设定数据包的重传次数（Retransmission_Number），在无线信号不佳时能有效避免音频卡顿-。
• 推进ASE状态：它是推动音频流端点 (ASE) 状态机从“编解码器已配置 (Codec Configured)”状态进入“QoS已配置 (QoS Configured)”状态的关键一步，标志着数据通道准备就绪。

⚙️ 其主要参数

Config QoS 操作涉及的关键参数，决定了音频传输的整体质量。

参数	说明
SDU_Interval	两个连续SDU之间的时间间隔，决定了音频数据包的发送频率，单位是微秒（μs）
SDU_Size	每个SDU（发送的数据包）能够承载的最大有效数据量。
Retransmission_Number	在链路层允许的最大重传次数，用来对抗无线干扰，保障音频的流畅性
Max_Transport_Latency	数据从发送端到接收端所允许的最大传输延迟时间，单位是毫（ms）
Presentation_Delay	从音频数据包被接收，到它从耳机等设备播放出来的所需延迟，是保证音画同步、多设备同步播放的关键参数
PHY	指定使用的物理层传输速率，例如可选的1M PHY（标准速率）、2M PHY（高速率）或Coded PHY（长距离）
Framing	定义ISOAL层是否需要添加帧头，是决定数据封装方式的一个数。

Config QoS 操作与其他的 ASE 控制操作共同构成了一个标准化的流程。理解这个流程的上下文，能更好地把握其在整个音频流生命周期中的位置。

🔄 Config QoS 在 ASE 生命周期中的位置

Config QoS 操作发生在从配置编解码器（Config Codec）之后、到启用（Enable）音频流之前的这个阶段，它是音频流协商流程中的关键一步：

• Idle (空闲)：音频流端点 (ASE) 的初始状态，尚未进行任何配置。
• Config Codec (配置编解码器)：客户端发起该操作，为ASE选择并配置音频的编码格式（如采样率、声道数等），ASE进入 Codec Configured (编解码器已配置) 状态。
• Config QoS (配置服务质量)：你正在了解的步骤，客户端在此阶段为ASE配置传输参数，ASE进入 QoS Configured (QoS已配置) 状态。

💡 注意：Config Codec 和 Config QoS 是 顺序依赖 的，必须先成功完成编解码器配置，才能进行服务质量配置，二者的顺序不可颠倒。

💁‍♀️ 一个典型的操作流程

下面是一个简化的 Config Qos 操作流程示例：

前置条件：单播服务器（耳机）已完成 Config Codec 操作，ASE 已处于 Codec Configured 状态，并且客户端已通过 ASE 状态通知获得了服务器偏好的 QoS 参数（如 Preferred_PHY、Preferred_Retransmission_Number、Max_Transport_Latency、Presentation_Delay_Min/Max 等）。

1. 根据服务器的 QoS 偏好，决策并准备 QoS 配置
   单播客户端（手机）根据服务器之前通知的 QoS 偏好参数（例如偏好 2M PHY、重传次数 2、最大传输延迟 10 ms、呈现延迟范围 20–40 ms 等），结合自身能力，选择具体的 QoS 参数值（如 PHY = 2M、重传次数 = 2、传输延迟 = 10 ms、呈现延迟 = 30 ms）。
2. 发起 Config QoS 操作（包含选定的 QoS 参数）
   客户端通过 ASE Control Point 特性写入 Config QoS 命令（Opcode = 0x02），携带 ASE ID 以及该 ASE 的完整 QoS 参数：Framing、PHY、Retransmission_Number、Max_Transport_Latency、Presentation_Delay 等。
3. 校验请求的 QoS 参数是否在服务器支持范围内
   服务器收到命令后，校验每个参数：

• • 请求的 PHY 是否在其 Preferred_PHY 位域或实际支持范围内；
  • 请求的重传次数是否 ≤ 服务器声明的 Preferred_Retransmission_Number（若该值 ≠ 0xFF）；
  • 请求的 Max_Transport_Latency 是否 ≤ 服务器之前给出的最大值；
  • 请求的 Presentation_Delay 是否在 [Presentation_Delay_Min, Presentation_Delay_Max] 区间内。
    若全部通过，则接受配置；否则返回对应错误码。

1. 通知（Notify）操作结果（成功）
   服务器通过 ASE Control Point 特性发送通知，返回操作成功响应。
   同时，服务器将对应 ASE 的状态从 Codec Configured 转换为 QoS Configured。
2. 更新并通知 ASE 的 QoS Configured 状态
   服务器更新 ASE 状态特性，并通过通知（Notify）将新的 QoS Configured 状态发送给客户端，客户端可以据此确认配置成功。

结果：Config QoS 成功完成，ASE 已进入 QoS Configured 状态，可以进入下一阶段（Enable 操作，开始音频流传输）。

二. 流程介绍

1. 状态机管理

我们在这个之前已经介绍过了ASCS的状态机，对应的Source/Sink流转如下：

从这个表格中可以看到在什么时机可以发送Config Qos，并且只有client可以发送，一目了然，下面我们就来介绍下Config Qos的流程

2. 流程介绍

我们在前面已经介绍过流程了，跟下面的基本没有区别，下面的是BAP协议的sample流程示意图：

有了这个流程图，我们就结合btsnoop来说明下每个命令或者通知的格式

a. client设置CIG参数

格式如下：

📢 命令详解：它做了什么？

此命令的核心职责包括：

• 创建等时组（CIG）：LE Audio 支持多重串流，可以将多个去往不同设备的音频流（CIS）打包成一个组（CIG），以实现精准同步。这个命令就是用来创建这个组并配置其公共属性。
• 定义传输参数：为组内的所有流定义统一的节奏，即从中央设备到外围设备（SDU_Interval_C_To_P）和从外围设备到中央设备（SDU_Interval_P_To_C）的间隔，它决定了音频数据包的发送频率。
• 确定传输延迟上限：为每个流分别设置最大可容忍的端到端传输延迟上限（Max_Transport_Latency)。
• 指定物理层：要求链路层使用特定的物理层传输速率（PHY），例如高带宽的 2M PHY 或省电的 Coded PHY。
• 安排子事件模式：Packing 参数是给控制器的建议，指示多个流的子事件（Subevent）在时间轴上是顺序（Sequential）排列还是交错（Interleaved）排列。
• 识别帧格式：Framing 参数定义了 CIS 数据 PDU 的格式。
• 处理时钟漂移：Worst_Case_SCA 参数允许主机告知控制器所有外围设备中最差的休眠时钟精度，以便控制器更好地安排子事件时序，避免因时钟漂移导致同步错误。

🔗 命令的输入输出参数

参数方向	参数名	说明
输入：CIG 级别	CIG_ID	主机指定的 CIG 标识符
	SDU_Interval_C_To_P	中央设备发送连续SDU的时间间隔
	SDU_Interval_P_To_C	外围设备发送连续SDU的时间间隔
	Worst_Case_SCA	所有参与CIS的外围设备中最差的休眠时钟准确度
	Packing	多个CIS子事件的排列方式（顺序或交错）
	Framing	请求的CIS Data PDU帧格式
输入：CIS 级别	CIS_ID	主机指定的CIS标识符。
	Max_Transport_Latency_C_To_P	中央到外围的最大传输延迟（ms）
	Max_Transport_Latency_P_To_C	外围到中央的最大传输延迟（ms）
	PHY_C_To_P / PHY_P_To_C	指定两个方向上使用的 PHY 类型 (1M, 2M, Coded)
	RTN_C_To_P / RTN_P_To_C	两个方向上最大重传次数。
输出	Status	命令执行状态。
	CIG_ID	输入的 CIG_ID。
	CIS_Handles	为每个 CIS 分配的唯一句柄

💡 与其他 HCI 命令的配合(这个在后续的op会介绍牵扯到)

HCI_LE_Set_CIG_Parameters 并非孤立工作，它与一组 HCI 命令协同完成 LE Audio 数据流的建立：

• HCI_LE_Create_CIS：在 Set CIG Parameters 命令完成后，由主机调用，用于实际创建 CIG 内的一个或多个 CIS 连接。
• HCI_LE_Setup_ISO_Data_Path：在 CIS 创建成功后，用于配置等时数据路径，将音频数据从主机通过控制器发送出去。
• HCI_LE_Remove_CIG：用于移除一个 CIG 及其所有关联的 CIS。

后续就是协议层面的交互了，过程如下：

b. 发起 Config QoS 操作（包含选定的 QoS 参数）

字段 (Field)	大小	描述 (Description)
Opcode	1	0x02= Config QoS
Number_of_ASEs	1	本次 Config QoS 操作涉及的 ASE 总数，须 ≥ 1
ASE_ID[i]	1	该 ASE 的标识符
CIG_ID[i]	1	客户端为该 ASE 写入的 CIG_ID 参数值（若使用 HCI，则通过 LE Set CIG Parameters 命令写入）
CIS_ID[i]	1	客户端为该 ASE 写入的 CIS_ID 参数值（若使用 HCI，则通过 LE Set CIG Parameters 命令写入）
SDU_Interval[i]	3	客户端为该 ASE 写入的 SDU_Interval 参数值（若使用 HCI，则通过 LE Set CIG Parameters 命令写入） 范围：0x0000FF– 0x0FFFFF，其他值 RFU
Framing[i]	1	客户端为该 ASE 写入的 Framing 参数值（若使用 HCI，则通过 LE Set CIG Parameters 命令写入） • 0x00：Unframed • 0x01：Framed • 其他值 RFU
PHY[i]	1	客户端为该 ASE 写入的 PHY 参数值（若使用 HCI，则通过 LE Set CIG Parameters 命令写入） 位域： • 0b00000001：LE 1M PHY • 0b00000010：LE 2M PHY • 0b00000100：LE Coded PHY • 其他位 RFU
Max_SDU[i]	2	客户端为该 ASE 写入的 Max_SDU 参数值（若使用 HCI，则通过 LE Set CIG Parameters 命令写入） 范围：0x00– 0x0FFF，其他值 RFU
Retransmission_Number[i]	1	客户端为该 ASE 写入的重传次数参数（若使用 HCI，则通过 LE Set CIG Parameters 命令写入） 范围：0x00– 0xFF，其他值 RFU
Max_Transport_Latency[i]	2	客户端为该 ASE 写入的 Max_Transport_Latency 参数值（若使用 HCI，则通过 LE Set CIG Parameters 命令写入） 范围：0x0005 – 0x0FA0，其他值 RFU
Presentation_Delay[i]	3	客户端为该 ASE 请求的呈现延迟参数值 单位：µs

c. 通知（Notify）操作结果（成功）

格式如下：

字段 (Field)	大小 (Octets)	描述 (Description)
Opcode	1	本次响应对应的客户端发起的 ASE 控制操作的操作码（例如 Config Qos 的 Opcode 为 0x02）
Number_of_ASEs	1	服务器提供响应的 ASE 总数。 若 Response_Code 值为 0x01 或 0x02，则此字段应设为 0xFF。
ASE_ID[i]	1	该 ASE 的标识符。 若 Response_Code 值为 0x01 或 0x02，则 ASE_ID 应设为 0x00，且循环索引 i 设为 0（即仅有一个虚拟项）。
Response_Code[i]	1	若服务器成功完成客户端发起的 ASE 控制操作，则设为 0x00；否则设为表 5.1 中定义的错误码。
Reason[i]	1	若服务器成功完成操作，则设为 0x00；否则设为表 5.1 中定义的原因值。 若 Response_Code 值为 0x01 或 0x02，则循环索引 i 设为 0（即无实际 ASE 项）。

d. 更新并通知 ASE 的 Qos Configured 状态

格式如下：

字段 (Field)	大小	描述 (Description)
CIG_ID	1	客户端在 Config QoS 操作中为该 ASE 写入的 CIG_ID 参数值
CIS_ID	1	客户端在 Config QoS 操作中为该 ASE 写入的 CIS_ID 参数值
SDU_Interval	3	客户端在 Config QoS 操作中为该 ASE 写入的 SDU_Interval 参数值 范围：0x0000FF – 0x0FFFFF，其他值 RFU
Framing	1	客户端在 Config QoS 操作中为该 ASE 写入的 Framing 参数值 • 0x00：Unframed • 0x01：Framed • 其他值 RFU
PHY	1	客户端在 Config QoS 操作中为该 ASE 写入的 PHY 参数值（位域） • 0b00000001：LE 1M PHY • 0b00000100：LE 2M PHY • 0b00001000：LE Coded PHY • 其他位 RFU
Max_SDU	2	客户端在 Config QoS 操作中为该 ASE 写入的 Max_SDU 参数值 范围：0x00 – 0xFFF，其他值 RFU
Retransmission_Number	1	客户端在 Config QoS 操作中为该 ASE 写入的重传次数参数值范围：0x00– 0xFF，其他值 RFU
Max_Transport_Latency	2	客户端在 Config QoS 操作中为该 ASE 写入的 Max_Transport_Latency 参数值 范围：0x0005 – 0x0FA0，单位：ms，其他值 RFU
Presentation_Delay	3	客户端在 Config QoS 操作中为该 ASE 写入的 Presentation_Delay 参数值,单位：µs