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

它，就是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 Receive Stop Ready的作用是什么？
• ASCS Receive Stop Ready的流程是什么？

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

一. Receive Stop Ready的作用

🎯 Receiver Stop Ready 操作的核心作用

Receiver Stop Ready（接收方停止就绪）是 ASCS 中专门用于通知发送端“接收方已停止接收音频数据”的关键控制指令-。它的核心使命是：

• 解除 CIS 与 ASE 的耦合关系，完成 UE「断开CIS」的最后闭环；
• 辅助 Source ASE 从 Disabling 状态正确退回到 QoS Configured 状态，为后续快速恢复或资源释放奠定基础；
• 给发送端一个明确信号——下游已停止接收，发送端不再发送音频数据。

从本质上看，Receiver Stop Ready 可以理解为一个“解绑信号”。在某些协议的实现中，Disable 操作执行后，Source ASE（发送端）只是停止发送数据，但它与 CIS（Connected Isochronous Stream）仍然绑在一起。而 Receiver Stop Ready 负责向发送端发出明确指令：“我已经停止接收了，可以安全解绑了”，从而使 Step 2 Disable 得以切换到 Step 3 Disabling，确保传输通道逻辑完整断开。

Receiver Start Ready 是“建立”，Receiver Stop Ready 就是“解除”。Receiver Stop Ready 是 Receiver Start Ready 的对称逆操作，也是 Source ASE 端流控正常退出的必经步骤。

与 Disable 不同，Disable 侧重于停止音频流传输并保留配置，但 CIS 耦合可能仍存在；Receiver Stop Ready 则专门负责解除 CIS 与 ASE 的绑定，配合 Disable 完成完整的流释放流程。

⚠️ 关键适用约束：仅 Source ASE 可用

Receiver Stop Ready 操作有一个非常重要的约束：它只能在 Source ASE（音频源端，即发送音频的设备）上使用，对 Sink ASE 无意义。如果服务器收到针对 Sink ASE 的 Receiver Stop Ready 指令，应当直接返回错误码 0x05（Invalid ASE Direction）并拒绝执行-。

这是因为 Sink ASE 作为接收端，本身没有“停止作为接收方”这种概念——接收端要么在听，要么不在流状态中，不需要一个独立的“停止就绪”指示来切断流水线。而 Source ASE 是发送端，当发送端需要停止发送数据时，必须通知接收端“我这边不发了”，避免接收端一直等待数据。

⚙️ Receiver Stop Ready 操作对 Source ASE 的状态转移路径

Receiver Stop Ready 整个流程有非常明确的适用状态和转移结果：

当前状态	是否允许	操作结果
Disabling (0x05)	✅ 允许	服务器执行解绑，状态移至 QoS Configured
Streaming (0x04)	✅ 允许	直接解绑后进入 QoS Configured （实际场景极少）
Enabling (0x03)	✅ 允许	资源尚未完全建立即可提前解绑
QoS Configured (0x02)	❌ 拒绝	未启用或已解绑，重复操作无意义，返回错误码 0x04
其他无效状态	❌ 拒绝	返回错误码 0x04

Receiver Stop Ready 的核心使命就是从 Source ASE 的 Disabling 状态解绑，进入 QoS Configured，并不依赖 Receiver Stop Ready 回退则永远卡在 Disabling。这意味着对实现来说：如果某个 Source ASE 执行了 Disable 进入 Disabling，但没有后续的 Receiver Stop Ready，ASE 将永远无法到达 QoS Configured，从而导致音频资源无法正常回收，甚至可能影响下次 Enable 操作。

🔍 Receiver Stop Ready 操作细节：与 Disable 的对比

Receiver Stop Ready 与 Disable 在流停止流程中分工明确：

操作	触发方	适用方向	适用状态	目标状态
Disable	客户端或服务器	Sink + Source	Enabling、Streaming	Sink➜QoS Configured / Source➜Disabling
Receiver Stop Ready	仅客户端	仅 Source ASE	Disabling	QoS Configured

从定位来看：

• Disable：发出“停止数据”的信号，Sink 直接退回到 QoS Configured，Source 则进入 Disabling（待命解绑）；
• Receiver Stop Ready：发出“我已停止接收”的信号，仅 Source ASE 收到后可安全、完整解绑 CIS，状态机最终退回到 QoS Configured。

⚠️ Receiver Stop Ready 操作的前置条件

Receiver Stop Ready 仅在 ASE处于 Disabling 状态时才能够正确执行。规范中也明确规定：当 ASE 处于 Disabling 状态时，服务器应当接受客户端的 Receive Stop Ready 操作。这是因为：

• 如果 ASE 是 Source ASE，在执行 Disable 后会进入 Disabling 状态等待解绑；
• 客户端在收到 Disabling 状态通知后，可发起 Receiver Stop Ready 以完成当前解绑。如果在 Disabling 状态下没有发送该指令，ASE 将永远卡住无法退回到 QoS Configured。

📎 Receiver Stop Ready 操作流程图

📖 文字说明（分步解读）

前置条件

Receiver Stop Ready 仅在 Source ASE处于 Disabling (0x05) 状态时执行。Disabling 状态通常在客户端发送 Disable 指令并成功执行后由服务器切换进入。

第 1 步：客户端发起 Receiver Stop Ready 操作

客户端（如手机）向服务器的 ASE Control Point 特征写入 Receiver Stop Ready 操作码（0x06），并附带需要停止的 Source ASE_ID。可一次传入多个 ASE_ID 批量处理。

第 2 步：服务器校验与响应

服务器收到请求后，检查：

• 操作码是否有效（0x06）；
• 目标 ASE 是否为 Source ASE（如果仅为 Sink ASE，直接返回错误码 0x05 Invalid ASE Direction）；
• 目标 ASE 是否处于 Disabling 状态（如果不是，返回错误码 0x04 Invalid ASE State Machine Transition）。

校验通过后，服务器立即通过 ASE Control Point 特征返回 Success 响应（Response Code 0x00），确认指令被接受。

第 3 步：执行 CIS 通道解绑

服务器执行底层操作，解除 CIS（Connected Isochronous Stream）与 ASE 的耦合关系。这意味着音频数据的传输完全停止，Receiver Start Ready 阶段建立的逻辑连接被安全断开。这是流数据彻底停止的“最后收尾”环节。

第 4 步：停止音频数据接收/发送

服务器确保音频数据的接收/发送完全停止，相关资源释放。

第 5 步：状态转换与通知

ASE 状态从 Disabling (0x05) 转换为 QoS Configured (0x02)。服务器通过 ASE 特征值 发送状态通知，告知客户端 ASE 已回到配置就绪状态。

结束状态

ASE 处于 QoS Configured (0x02)，编解码器配置和 QoS 参数保留。如需彻底释放资源，客户端可继续发送 Release 操作将 ASE 重置为 Idle；如需恢复音频传输，可直接发送 Enable 从 QoS Configured 转到 Streaming。

🔁 Receiver Stop Ready vs Disable vs Release 对比

操作	核心目的	适用 ASE 方向	适用状态	目标状态	参数是否保留	典型场景
Disable	临时停止音频流，配置保留	Sink + Source	Enabling、Streaming	Sink➜QoS Configured / Source➜Disabling	编解码器 + QoS 保留	暂停音乐、通话保持
Receiver Stop Ready	解除 CIS 绑定，完成流停止闭环	仅 Source ASE	Disabling	QoS Configured	编解码器 + QoS 保留	发送端主动停止上行音频（如耳机麦克风停用）
Release	彻底释放所有配置	Sink + Source	多种状态（除 Idle）	Releasing → Idle	全部释放	断开连接、切换音频设备

这三者的协作关系可以这样理解：一个 Source ASE 的正常流停止流程是 Disable → Disabling → Receiver Stop Ready → QoS Configured（或转 Release），缺少任何一步，ASE 的状态机就可能乱或资源无法回收。Disable 负责停止数据传输并进入 Disabling，Receiver Stop Ready 负责通知接收端解绑 CIS，最终回到 QoS Configured；Release 则是最后的彻底回收。

📌 实践要点

1. Receiver Stop Ready 仅适用于 Source ASE：如果服务器收到针对 Sink ASE 的该指令，应返回 0x05 Invalid ASE Direction，不要执行任何后续操作-。
2. Disable + Receiver Stop Ready 形成完整停止流程：对 Source ASE 来说，单纯的 Disable 只会停止数据发送但不会解绑 CIS；必须配合 Receiver Stop Ready 才能将 ASE 彻底退回 QoS Configured。缺少该指令时可能导致 CIS 仍粘附 ASE 资源。
3. 批量处理支持：Receiver Stop Ready 支持一次传入多个 ASE_ID，服务器需“逐个校验、逐个执行、批量返回”（类似于 Enable 和 Disable），且当某个 ASE 校验失败时不应影响其他 ASE 的正常执行。
4. 安全约束：所有 ASE Control Point 操作均要求加密连接（Encryption required），防止指令被窃取或篡改。实现时需确保传输链路已加密。
5. 链路丢失的自主处理：若 ACL 链路丢失，服务器应自主将 ASE 直接转为 Releasing 状态，而非等待客户端的 Receiver Stop Ready，因为此时客户端已无法发送任何指令。
6. 内存与资源回收：不发送 Receiver Stop Ready 则 Source ASE 停留在 Disabling，CIS 无法解绑，内存和 CID 资源无法回收，可能中断后续 Enable 请求。这对于需要长时间稳定工作的设备尤其关键

二. 流程介绍

1. 状态机管理

我们在前面也已经介绍了，只有Source ASE才适用

2. 流程介绍

官方的BAP协议把上面两种情况都放到一张流程图中了，所以有点难理解，但是你看我上面的流程图应该比较好理解！

上面的流程图是包含了Source跟Sink的流程，其中i是unicast Server作为Sink,j是unicast Server作为Source

a. 发起 receive stop ready操作过程

字段	大小（字节）	描述
Opcode	1	0x06 = Receiver Stop Ready
Number_of_ASEs	1	本次 Disable 操作涉及的 ASE 总数，必须 ≥ 1
ASE_ID[i]	1	第 i 个 ASE 的标识符

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

格式如下：

字段 (Field)	大小 (Octets)	描述 (Description)
Opcode	1	本次响应对应的客户端发起的 ASE 控制操作的操作码（例如 receive stop ready 的 Opcode 为 0x06）
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 项）。

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

ⅰ. Source通知

格式如下：

字段 (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