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

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

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

一. Update Metadata的作用

🎯 Update Metadata 操作的核心作用

在 LE Audio 的音频流生命周期中，客户端（如手机）通常只需要在 Enable 时下发一次元数据（Metadata）。但在某些应用场景下，场景切换后，客户端需要更新已启用音频流的元数据，Update Metadata 操作正是为此而生。它支持在不中断音频流的前提下，动态调整当前音频上下文的属性，使音频传输能实时适配用户的交互需求。

例如，在音乐播放期间进入电话呼入，音频流需要立即从“音乐”切换为“语音通话”，改变音效处理策略（如关闭低音增强，开启回声消除），这正是 Update Metadata 操作最适用的场景之一。

核心意义在于：它让音频流的 Enable 动作从一次性的“初始配置”，进化为能够响应场景变化的动态维护，真正实现了无缝的用户体验（例如音乐无缝切换到通话）。

📎 Update Metadata 操作流程图

前置条件

目标 ASE 必须处于 Streaming (0x04) 状态。如果在 QoS Configured、Enabling 或 Disabling 状态调用 Update Metadata，服务器会返回错误码 0x04（Invalid ASE State Machine Transition）。

步骤 1：客户端准备新元数据

根据应用场景的变化（例如从音乐播放切换到语音通话，或激活语音助手），客户端生成新的 LTV 格式元数据。典型的元数据包括音频上下文类型（0x02 对话、0x03 媒体等）以及厂商自定义的扩展信息。

步骤 2：客户端发起 Update Metadata 操作

客户端向服务器的 ASE Control Point 特征写入操作码 0x07，并附上目标 ASE_ID 和新元数据。如果需要同时更新多个 ASE，可设置 Number_of_ASES > 1 并依次列出 ASE_ID[i]、Metadata_Length[i]、Metadata[i]。

步骤 3：服务器校验并更新元数据

服务器收到请求后，进行以下检查：

• 操作码是否为 0x07；
• 目标 ASE 是否存在且方向有效；
• 目标 ASE 当前状态是否等于 Streaming；
• 元数据的 LTV 格式是否合法（Length 字段必须包含 Type + Value 的总字节数），以及 Type 值是否在 PACS 记录中声明支持。

校验通过后，服务器将新元数据存储到该 ASE 的上下文中，ASE 状态保持不变（仍为 Streaming）。

步骤 4：返回操作成功通知（ASE Control Point）

服务器通过 ASE Control Point 特征返回 Success 响应（Response Code 0x00）。这是对 Update Metadata 指令的即时确认。

步骤 5：根据新元数据调整内部音频处理

服务器根据更新后的元数据，实时调整内部音频处理策略，例如：

• 关闭音乐模式下的低音增强，开启通话模式下的回声消除和噪声抑制；
• 更改重采样率或音频路由（将音频从媒体播放器切换到通话编解码器）；
• 触发厂商特定的音效配置切换。

整个过程不中断正在进行的音频流，用户几乎无感知。

步骤 6：发送 ASE 特征值通知（确认当前状态）

为了消除客户端的疑虑并明确告知“流仍然处于 Streaming 状态”，服务器可以（或应该） 通过 ASE 特征值发送一次状态通知，将当前 ASE 状态显式报告为 Streaming (0x04)。这样做的好处是：

• 客户端可以明确得知元数据已生效且流状态健康；
• 避免客户端因未收到状态更新而误认为操作失败或流已中断。

二. 流程介绍

1. 状态机管理

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

2. 流程介绍

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

a. 发起 update metadata操作过程

字段	大小	描述
Opcode	1	0x07= Update Metadata
Number_of_ASES	1	本次 Update Metadata 操作涉及的 ASE 总数，必须 ≥ 1
ASE_ID[i]	1	第 i 个 ASE 的标识符
Metadata_Length[i]	1	第 i 个 ASE 对应的 Metadata 参数长度
Metadata[i]	可变	LTV 格式的元数据，仅当 Metadata_Length[i] ≠ 0x00 时才存在

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

格式如下：

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

这个当前状态不会变，继续保持enabling/streaming的状态