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

它，就是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 release/released的作用是什么？
• ASCS release/released的流程是什么？

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

一. release/released的作用

根据规范重新梳理 Release 与 Released 的关系：

• Release：由客户端发起的操作，请求服务器释放指定 ASE 的资源。
• Released：由服务器自主发起的操作，用于通知客户端释放已完成，并根据是否缓存编解码器配置，将 ASE 最终置于 Codec Configured 或 Idle 状态。

下面制作流程图和文字说明。

---

🔁 Release 与 Released 完整流程（规范版）

📖 文字介绍

1. Release 操作（客户端发起）

• 作用：客户端请求服务器释放一个或多个 ASE。
• 参数：操作码 0x08 + Number_of_ASEs + ASE_ID 列表。
• 流程：

• • 服务器校验 ASE 状态（不能为 Idle 或 Codec Configured，否则无资源可释放）。
  • 校验通过后，返回 Success 响应，ASE 进入 Releasing 过渡状态。
  • 服务器内部拆除底层 CIS、清空 QoS 参数、释放等时通道资源。
  • 控制器确认 CIS 已拆除。

2. Released 操作（服务器自主发起）

• 触发条件：

• • 条件A：客户端主动发起的 Release 已完成，且底层 CIS 已拆除。
  • 条件B：服务器检测到 LE-ACL 链路丢失（无需客户端指令）。

• 作用：通知客户端最终释放结果，并根据是否缓存编解码器配置来决定 ASE 最终状态。

3. 两种最终状态的处理

是否缓存 Codec 配置	ASE 最终状态	附加操作
是	Codec Configured (0x01)	写入 Codec_ID、Codec_Specific_Configuration等参数（已配置值或服务器首选值）；同时写入其余 Additional_ASE_Parameters字段的首选值。
否	Idle (0x00)	删除所有 Additional_ASE_Parameters字段。

4. 关键要点

• Released 是服务器自主发送的通知，客户端不需要（也不能）主动发送 Released。
• 客户端应监听 ASE 特征值的变化，根据收到的最终状态（Codec Configured 或 Idle）决定后续动作：

• • 若为 Codec Configured，下次建立流时可以跳过 Config Codec，直接从 Config QoS 开始。
  • 若为 Idle，下次必须从 Config Codec 重新配置。

• 规范允许服务器缓存编解码器配置，这可以减少重新配置时间，适用于快速重连场景。

二. 流程介绍

1. 状态机管理

我们在前面也已经介绍了，Sink/Source操作如下图：

2. 流程介绍

a. 发起 release操作过程

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

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

格式如下：

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

releasing是没有参数的

又又又又发现ellisys一个解析bug,哈哈

d. 释放iso通道

e. server自动决定是否缓存通知相应的状态