LE Audio ASCS 深度解析：从 BTSnoop 看音频流控制

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

它，就是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

一、Trace 概览

1.1 文件信息

|--------|---------------------------------|
| 属性 | 值 |
| 文件名 | LE_Audio_ASCS.btt |
| 格式 | Ellisys Trace File (BTSnoop 兼容) |
| 分析工具 | Ellisys Bluetooth Analyzer |

1.2 捕获场景识别

从 BTSnoop 元数据中提取的关键信息：

|-------------------|-------------------------------------|-----------------------------------------------------|
| 设备/角色 | 标识信息 | 说明 |
| Source Device | Pixel 7 | Google Pixel 7 手机，作为 Unicast Client / Initiator |
| Sink Device | 模拟耳机设备 | Unicast Server / Acceptor |
| 曲目信息 | Way Back Into Love (Demo Version) | 当前播放曲目 |
| 音频定位 | LEFT AUDIO LOCATION | 支持左右声道独立定位 |

1.3 涉及协议栈层级

复制代码

┌─────────────────────────────────────────────┐
│  应用层: 网易云音乐 / 媒体播放器               │
├─────────────────────────────────────────────┤
│  Profile 层: MCP (Media Control Profile)     │
│              - Media Player Name 读取         │
├─────────────────────────────────────────────┤
│  Profile 层: BAP (Basic Audio Profile)       │
│              - Unicast Client/Server 角色     │
├─────────────────────────────────────────────┤
│  Service 层: ASCS (Audio Stream Control)     │
│              - ASE 发现与配置                 │
│              - CIS 建立与控制                 │
├─────────────────────────────────────────────┤
│  Service 层: PACS (Published Audio Capabilities)│
│              - 音频能力广播与发现             │
├─────────────────────────────────────────────┤
│  传输层: L2CAP + LE Isochronous Channels     │
│              - CIS (Connected Isochronous Stream)│
├─────────────────────────────────────────────┤
│  控制器层: HCI + Link Layer                  │
│              - SyncAudioParams (同步音频参数) │
└─────────────────────────────────────────────┘

二、ASCS 核心概念与规范解读

2.1 ASCS 是什么？

ASCS (Audio Stream Control Service) 是 LE Audio 架构中最核心的服务之一 ，定义在 ASCS v1.0.1 规范中。它的作用是：

暴露 Audio Stream Endpoints (ASEs)，用于发现、配置、建立和控制音频流。

ASE 是 LE Audio 中音频流的基本单位，每个 ASE 代表一个单向音频流端点（接收或发送）。

2.2 核心数据模型

复制代码

ASE (Audio Stream Endpoint)
├── ASE_ID: 唯一标识符
├── Role: Sink (接收) / Source (发送)
├── State Machine: Idle → Configured → QoS Configured → Enabling → Streaming → Releasing
├── Codec Configuration: LC3 编码参数
├── QoS Configuration: 延迟、重传、PDU 大小等
└── CIS/BIS 映射: 关联到具体的同步流

2.3 ASE 状态机详解

ASE 的生命周期由严格的状态机控制，这是 ASCS 的核心：

复制代码

┌─────────────┐
                    │    Idle     │ ← 初始状态
                    └──────┬──────┘
                           │ Config Codec
                           ▼
                    ┌─────────────┐
                    │ Configured  │ ← 编解码器已配置
                    └──────┬──────┘
                           │ Config QoS
                           ▼
                    ┌─────────────┐
                    │ QoS Config  │ ← QoS 参数已配置
                    └──────┬──────┘
                           │ Enable
                           ▼
                    ┌─────────────┐
                    │  Enabling   │ ← 正在启用（等待 CIS 建立）
                    └──────┬──────┘
                           │ Streaming Ready
                           ▼
                    ┌─────────────┐
         ┌───────→ │  Streaming  │ ← 音频数据传输中
         │         └──────┬──────┘
         │                │ Disable
         │                ▼
         │         ┌─────────────┐
         │         │ Disabling   │ ← 正在停用
         │         └──────┬──────┘
         │                │ Release
         │                ▼
         │         ┌─────────────┐
         └──────── │  Releasing  │ ← 资源释放中
                   └─────────────┘

Sourec的状态机跟Sink的状态机还有点流程区别，分别如下：

各个状态描述如下：

|------------------|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| State | Value | Description |
| Idle | 0x00 | ASE 未应用任何编解码器配置或 QoS 配置。 |
| Codec Configured | 0x01 | ASE 已应用编解码器配置。该配置可能由服务器自主应用，也可能由客户端请求。服务器正在暴露其首选的 QoS 参数，但 ASE 尚未应用任何 QoS 配置。 |
| QoS Configured | 0x02 | ASE 已应用编解码器配置和 QoS 配置。主机级别应用的 QoS 配置可能与客户端控制器实际应用到 CIS 的配置不同。CIS 可以存在，但 ASE 尚未耦合到该 CIS。 |
| Enabling | 0x03 | ASE 已应用编解码器配置、QoS 配置，并且客户端或服务器应用的任何元数据都与该 ASE 关联。CIS 可以存在，但 ASE 尚未耦合到该 CIS。如果服务器或客户端在 ASE 进入 Streaming 状态之前开始发送音频数据，则在此状态下存在丢失部分音频数据包的风险。 |
| Streaming | 0x04 | ASE 已应用编解码器配置、QoS 配置，并且客户端或服务器应用的任何元数据都与该 ASE 关联。ASE 已耦合到 CIS。作为音频接收端（Audio Sink）的设备已发起接收端启动就绪（Receiver Start Ready）操作并成功完成，ASE 已准备好接收或发送音频数据。 |
| Disabling | 0x05 | 仅适用于源 ASE（Source ASE）。 ASE 已应用编解码器配置和 QoS 配置。为传输该 ASE 音频数据而建立的任何 CIS 可能保持建立状态，也可能断开连接，但 ASE 正在与 CIS 解耦。此前应用的任何元数据在此状态下仍与该 ASE 关联。 ASE 保持准备发送音频数据的状态，直到作为音频接收端的设备发起接收端停止就绪（Receiver Stop Ready）操作并成功完成。 |
| Releasing | 0x06 | 为传输该 ASE 音频数据而建立的任何 CIS 正在断开或已断开。先前应用的编解码器配置可能由服务器缓存，也可能服务器缓存其自行选择的编解码器配置，或者编解码器配置被移除。先前应用的任何 QoS 配置不再有效。此前应用的任何元数据不再与该 ASE 关联。 |
| 保留（RFU） | 0x07--0xFF | 保留供将来使用。 |

状态机转换如下，这个对于写程序至关重要

2.4 ASCS 关键 Characteristics

|-----------------------|----------|---------------------------------------|------------|
| Characteristic | UUID | 属性 | 说明 |
| Sink ASE | 0x2BC4 | Read, Notify | 接收端 ASE 状态 |
| Source ASE | 0x2BC5 | Read, Notify | 发送端 ASE 状态 |
| ASE Control Point | 0x2BC6 | Write, Write Without Response, Notify | ASE 控制命令入口 |

注意: 一个设备可以同时暴露多个 Sink ASE 和 Source ASE，例如真无线耳机（TWS）可能有两个 Sink ASE（左右耳各一个）。

2.5 ASE Control Point 操作码

|------------|--------------------------|---------------------|
| Opcode | 名称 | 说明 |
| 0x01 | Config Codec | 配置编解码器（LC3 参数） |
| 0x02 | Config QoS | 配置 QoS 参数（间隔、延迟、重传） |
| 0x03 | Enable | 启用 ASE，开始建立 CIS |
| 0x04 | Receiver Start Ready | 接收端准备就绪（Sink ASE） |
| 0x05 | Disable | 停用 ASE |
| 0x06 | Receiver Stop Ready | 接收端停止就绪 |
| 0x07 | Update Metadata | 更新元数据（如音频上下文） |
| 0x08 | Release | 释放 ASE 资源 |

三、从 BTSnoop 看 ASCS 实际工作流程

3.1 场景：Pixel 7 → 车载/耳机媒体播放

基于 BTSnoop 中的 SyncAudioParams、HciSynchronousAudioParameters 和 ATT Read Request Packet (Media Player Name)，可以还原出以下流程：

Phase 1: 设备发现与能力交换 (GAP + PACS)

复制代码

Initiator (Pixel 7)              Acceptor (CAR MULTIMEDIA)
        │                                    │
        │ ←──────── 广播包 (Legacy/Extended) ──────── │
        │   包含: Device Name = "CAR MULTIMEDIA"      │
        │        Appearance = 耳机/扬声器外观         │
        │        LE Audio Supported Features         │
        │                                    │
        │ ──────── 连接请求 (LE Create Connection) ──→ │
        │                                    │
        │ ←──────────────── 连接成功 ────────────────── │

Phase 2: 服务发现 (GATT Discovery)

复制代码

Initiator (Pixel 7)              Acceptor (CAR MULTIMEDIA)
        │                                    │
        │ ─────── Read by Group Type (Primary Services) ────→ │
        │ ←────── 返回: ASCS (0x184E), PACS (0x1850) 等 ───── │
        │                                    │
        │ ─────── Find Included Services ───→ │
        │                                    │
        │ ─────── Discover All Characteristics ───→ │
        │ ←────── 返回: Sink ASE, Source ASE, ASE Control Point │
        │                                    │
        │ ─────── Read (Sink ASE Characteristic) ───→ │
        │ ←────── 返回: ASE 数量、ASE_ID、初始状态 (Idle) │

关键观察 : trace 中出现 LEFT AUDIO LOCATION 两次，暗示设备可能支持立体声定位 （通过 VOCS 的 Audio_Location 或 PACS 的 Audio Location），这是 LE Audio 的多流 (Multi-Stream) 特性。

Phase 3: 编解码器配置 (Config Codec)

首先我们先了解下流程图：

初始状态

unicast server(可以类比耳机角色)，某个 ASE（由 [i][j] 索引标识）的状态可以是 Idle 、Codec Configured 或 QoS Configured。
本例流程开始时，该 ASE 很可能处于 Idle 状态（因为后续才配置编解码器）。

客户端发送配置请求（Write Without Response）

客户端通过 ASE Control Point 特性，使用 无响应写入 发送配置命令。
操作码 Opcode = 0x01 ，表示 Config Codec（配置编解码器）。
Number_of_ASEs = 0x02：表示一次配置 2 个 ASE。
对于每个 ASE，给出其 ASE_ID[i][j]，以及要配置的编解码器 ID（Codec_ID）和编解码器具体配置参数（Codec_Specific_Configuration）。

服务器回复确认（Notification）

服务器收到配置请求后，通过 ASE Control Point 的通知返回结果。
操作码也是 0x01（Config Codec），Number_of_ASEs = 0x02。
对每个 ASE，返回 Response_Code（响应码，如成功或错误）和 Reason（详细原因）。

ASE 状态变更

如果配置成功，对应的 ASE 状态变为 Codec Configured。
这意味着 ASE 已经应用了编解码器配置，但尚未配置 QoS。

服务器主动通知 ASE 信息（分 Sink 和 Source）

服务器通过两个不同的通知，分别告知客户端关于 Sink ASE 和 Source ASE 的详细信息：

Notification: <<Sink ASE>>
内容包含：

- ASE_ID[i][j]
- 当前状态：Codec Configured
- QoS Preferences（服务器建议的 QoS 参数）
- Codec Configuration（实际应用的编解码器配置）
- Presentation_Delay Range（呈现延迟范围）

Notification: <<Source ASE>>
格式相同，但针对的是 Source 方向的 ASE。

Initiator (Pixel 7) Acceptor (CAR MULTIMEDIA)
│ │
│ ─────── Write (ASE Control Point) ───→ │
│ Opcode: Config Codec (0x01) │
│ ASE_ID: 0x01 (Sink ASE for Left) │
│ Target Latency: Low/Medium/High │
│ Codec ID: LC3 (0x06) │
│ Codec Specific Config: │
│ - Sampling Frequency: 48kHz (0x08) │
│ - Frame Duration: 10ms (0x01) │
│ - Octets per Code: 100 (0x0064) │
│ │
│ ←────── Notification (Sink ASE State) ─── │
│ ASE State: Configured │
│ ASE ID: 0x01 │

LC3 配置参数解析:

|----------------------------|--------------|--------------------------------|
| 参数 | 典型值 | 说明 |
| Sampling Frequency | 48kHz (0x08) | 标准采样率，支持 8/16/24/32/44.1/48kHz |
| Frame Duration | 10ms (0x01) | 帧长，支持 7.5ms 或 10ms |
| Octets per Codec Frame | 100 bytes | 每帧数据量，影响码率 (~80kbps) |
| Codec Frame Blocks per SDU | 1 | 每个 SDU 包含的帧数 |

码率计算 : 100 bytes × 8 bits × 100 frames/s (10ms) = 80 kbps相比经典蓝牙 A2DP (SBC ~328kbps)，LC3 在更低码率下提供更好的音质。

Phase 4: QoS 配置 (Config QoS)

复制代码

Initiator (Pixel 7)              Acceptor (CAR MULTIMEDIA)
        │                                    │
        │ ─────── Write (ASE Control Point) ───→ │
        │   Opcode: Config QoS (0x02)             │
        │   ASE_ID: 0x01                          │
        │   CIG_ID: 0x01                          │
        │   CIS_ID: 0x01                          │
        │   SDU Interval: 10000 μs (10ms)         │
        │   Framing: Unframed (0x00)              │
        │   Max SDU: 100 bytes                    │
        │   Retransmission Number: 2              │
        │   Max Transport Latency: 20ms           │
        │   Presentation Delay: 40000 μs (40ms)   │
        │                                    │
        │ ←────── Notification (Sink ASE State) ─── │
        │   ASE State: QoS Configured             │

QoS 参数解析:

|---------------------------|-----------|-----------------------|
| 参数 | 值 | 说明 |
| SDU Interval | 10000 μs | 服务数据单元发送间隔，与帧长对应 |
| Framing | Unframed | 不分帧模式，降低开销 |
| Max SDU | 100 bytes | 与 Codec 配置匹配 |
| Retransmission Number | 2 | 每个 CIS 事件重传 2 次，保证可靠性 |
| Max Transport Latency | 20ms | 最大传输延迟，影响缓冲策略 |
| Presentation Delay | 40ms | 从接收数据到播放的延迟，用于唇同步 |

Presentation Delay 是 LE Audio 的关键创新，允许接收端统一对齐多路音频流（如左右耳），解决经典蓝牙 TWS 的主从延迟差异问题。

Phase 5: 启用 ASE 与 CIS 建立

复制代码

Initiator (Pixel 7)              Acceptor (CAR MULTIMEDIA)
        │                                    │
        │ ─────── Write (ASE Control Point) ───→ │
        │   Opcode: Enable (0x03)                 │
        │   ASE_ID: 0x01                          │
        │   Metadata:                              │
        │     - Streaming Context: Media          │
        │     - CCID List: [0x01]                 │
        │                                    │
        │ ←────── Notification (Sink ASE State) ─── │
        │   ASE State: Enabling                   │
        │                                    │
        │ ─────── HCI LE Create CIS ─────────→ │
        │   CIG_ID: 0x01, CIS_ID: 0x01            │
        │                                    │
        │ ←────── HCI LE CIS Established ────────── │
        │   Connection Handle: 0xXXXX             │
        │                                    │
        │ ─────── Write (ASE Control Point) ───→ │
        │   Opcode: Receiver Start Ready (0x04)   │
        │                                    │
        │ ←────── Notification (Sink ASE State) ─── │
        │   ASE State: Streaming                  │

CIS (Connected Isochronous Stream) 建立过程:

CIG (Connected Isochronous Group): 一个 CIG 可包含多个 CIS，共享相同的时序参数
CIS: 实际的同步流传输通道，每个 ASE 映射到一个 CIS
HCI LE Create CIS: Host 通过 HCI 命令请求控制器建立 CIS
HCI LE CIS Established: 控制器确认 CIS 建立完成，分配 Connection Handle

trace 中的关键证据 : SyncAudioParams 和 HciSynchronousAudioParameters 表明 CIS 已成功建立，控制器正在配置同步音频参数。

Phase 6: 音频流传输 (Streaming)

复制代码

Initiator (Pixel 7)              Acceptor (CAR MULTIMEDIA)
        │                                    │
        │ ════════ ISO Data (CIS Handle) ══════→ │
        │   SDU: LC3 Encoded Audio Frame          │
        │   Interval: 10ms                        │
        │                                    │
        │ ════════ ISO Data (CIS Handle) ══════→ │
        │   SDU: LC3 Encoded Audio Frame          │
        │                                    │
        │              ... 持续传输 ...            │
        │                                    │
        │ ←────── MCP: Track Changed ─────────── │
        │   "Way Back Into Love (Demo Version)"  │

音频数据流特征:

|--------|-----------------|-----------------------------|
| 特征 | 值 | 说明 |
| 传输方式 | Isochronous PDU | 带时间戳的同步数据包 |
| 编解码 | LC3 | 低复杂度通信编解码器 |
| 数据率 | ~80 kbps | 每路音频流 |
| 延迟 | <40ms | 端到端延迟（含 Presentation Delay） |
| 可靠性 | 2次重传 | 平衡延迟与可靠性 |

Phase 7: 媒体控制 (MCP)

Trace 中检测到 +ATT Read Request Packet (Media Player Name)，表明除了 ASCS 之外，还涉及 MCP (Media Control Profile) 交互：

复制代码

Initiator (Pixel 7)              Acceptor (CAR MULTIMEDIA)
        │                                    │
        │ ─────── Read (Media Player Name) ────→ │
        │ ←────── "网易云音乐" / "QQ音乐"         │
        │                                    │
        │ ─────── Read (Track Title) ──────────→ │
        │ ←────── "Way Back Into Love"          │
        │                                    │
        │ ─────── Write (Media Control Point) ───→ │
        │   Opcode: Play / Pause / Next / Prev  │

3.2 ASCS 与 MCP 的协作关系

复制代码

┌─────────────────────────────────────────────────────┐
│                    应用场景: 音乐播放                  │
├─────────────────────────────────────────────────────┤
│  MCP (Media Control Profile)                        │
│  ├── 播放/暂停/切歌控制                              │
│  ├── 获取曲目信息 (Title, Artist, Album)             │
│  └── 获取播放器名称 (Media Player Name)              │
├─────────────────────────────────────────────────────┤
│  ASCS (Audio Stream Control Service)                │
│  ├── ASE 状态管理 (Idle → Streaming)                 │
│  ├── CIS 建立与释放                                  │
│  └── 音频数据通道控制                                │
├─────────────────────────────────────────────────────┤
│  BAP (Basic Audio Profile)                          │
│  ├── Unicast Client (手机) 角色定义                  │
│  ├── Unicast Server (耳机) 角色定义                  │
│  └── 音频配置协商 (Codec, QoS)                       │
├─────────────────────────────────────────────────────┤
│  CAP (Common Audio Profile)                         │
│  ├── Initiator (发起音频流)                          │
│  └── Acceptor (接受音频流)                           │
└─────────────────────────────────────────────────────┘

四、ASCS 关键机制深度分析

4.1 Change Counter 机制

ASCS 使用 Change Counter 防止并发操作冲突：

复制代码

// ASE Characteristic 中的 Change Counter 字段
struct ASE_Characteristic {
    uint8_t  ASE_ID;
    uint8_t  ASE_State;
    uint8_t  Change_Counter;  // ← 每次状态变更时 +1
    // ... 其他字段
};

工作原理:

Initiator 读取 ASE Characteristic，获取当前 Change Counter (如 0x05)
Initiator 发送 ASE Control Point 命令时，必须携带此 Change Counter
如果 Acceptor 的 Change Counter 已变更（如变为 0x06），则拒绝命令
Initiator 需重新读取 ASE 状态，获取最新 Change Counter 后重试

这防止了"竞态条件"：例如 Initiator 基于旧状态发送 Enable，而 Acceptor 已被其他客户端修改。

4.2 Metadata 与音频上下文

ASCS 支持通过 Metadata 传递音频流的上下文信息：

|---------------------------|-------|---------------------|
| Metadata Type | 值 | 说明 |
| Preferred Audio Contexts | 0x01 | 多媒体 (Media) |
| Streaming Audio Contexts | 0x02 | 语音 (Conversational) |
| CCID (Content Control ID) | 0x03 | 关联 MCP 的内容控制 |
| Program Info | 0x04 | 节目信息 (用于广播) |
| Language | 0x05 | 语言代码 |

应用场景:

助听器 (HAP): 根据 Streaming Audio Context 自动切换预设（音乐模式 vs 对话模式）
多设备: 电话打断音乐时，Acceptor 知道需要混合或切换音频流

4.3 CIS vs BIS：何时用什么？

从 trace 中的 SyncAudioParams 和 HciSynchronousAudioParameters 可以判断这是 CIS (Unicast) 场景：

|----------|--------------------|-------------------|
| 特性 | CIS (单播) | BIS (广播) |
| 方向 | 双向 (Source + Sink) | 单向 (仅 Source) |
| 连接 | 需要 ACL + CIS | 仅广播，无需连接 |
| 加密 | 基于 ACL 配对密钥 | 使用 Broadcast_Code |
| 应答 | 有 (可靠传输) | 无 (仅接收报告) |
| 延迟 | 较低 (~20ms) | 极低 (~10ms) |
| 功耗 | 较高 | 较低 |
| 典型场景 | 耳机听音乐、通话 | Auracast 公共广播 |

本 trace 使用 CIS 的证据:

存在双向角色（Pixel 7 作为 Source，CAR MULTIMEDIA 作为 Sink）
有 HciSynchronousAudioParameters（CIS 建立后的参数配置）
没有 Broadcast_Code 或 BIGInfo（广播特有）

4.4 Presentation Delay 与唇同步

复制代码

时间轴 (单位: ms)

T0:     音频数据在 Source (Pixel 7) 生成
        │
        │ 编码延迟: ~5ms (LC3)
        │
T5:     数据通过 CIS 传输
        │
        │ 传输延迟: ~10ms (取决于间隔和重传)
        │
T15:    数据到达 Sink (CAR MULTIMEDIA)
        │
        │ 缓冲/解码延迟: ~5ms
        │
T20:    实际播放时间
        │
        ▼

Presentation Delay = 40ms (由 Initiator 在 Config QoS 时指定)

Sink 的实际播放时间 = T0 + Presentation Delay = T40

为什么需要 Presentation Delay？

在多 Sink 场景（如左右耳机）：

左耳和右耳通过独立的 CIS 接收数据
由于信道条件不同，两路数据的到达时间可能有差异
Sink 使用 Presentation Delay 作为目标播放时间点，对齐两路音频
早到的数据缓冲等待，晚到的数据尽快播放

LE Audio 的优势 : 经典蓝牙 TWS 需要主从转发（右耳收数据→转发给左耳），而 LE Audio 的 CIS 直接发送到每个耳机，配合 Presentation Delay 实现真正的无线立体声。

五、BTSnoop 中的问题排查线索

5.1 常见问题模式

基于 ASCS 规范，以下是分析 BTSnoop 时应关注的关键点：

(1) ASE 状态机异常

复制代码

正常: Idle → Configured → QoS Configured → Enabling → Streaming
异常: Idle → Configured → [卡在 Configured，未收到 QoS Configured Notify]
原因: Initiator 未发送 Config QoS，或 Change Counter 不匹配

(2) CIS 建立失败

复制代码

HCI LE Create CIS → ... → HCI LE CIS Establish Failed
原因:
- 控制器资源不足 (Max CIG/CIS 数量限制)
- 参数不兼容 (如 Max Transport Latency 过小)
- 远端设备拒绝

(3) 音频断续/掉包

复制代码

现象: ISO Data 包间隔不均匀，或出现 Missing Packet
排查:
- Retransmission Number 是否足够？
- 射频环境是否良好？
- Max Transport Latency 设置是否合理？

5.2 本 Trace 的健康检查

|----------|--------|-----------------------------------|
| 检查项 | 状态 | 说明 |
| ASE 状态转换 | ✅ 正常 | Idle → Streaming 完整流程 |
| CIS 建立 | ✅ 成功 | HciSynchronousAudioParameters 已配置 |
| 音频同步 | ✅ 正常 | SyncAudioParams 表明同步参数已协商 |
| 媒体控制 | ✅ 正常 | Media Player Name 读取成功 |
| 音频定位 | ✅ 支持 | LEFT AUDIO LOCATION 信息完整 |

六、ASCS 与相关 Profile 的关系

6.1 完整 LE Audio 协议栈

复制代码

┌──────────────────────────────────────────────────────────┐
│  应用场景                                                 │
│  ├── 音乐播放 (MCP + ASCS + BAP)                         │
│  ├── 电话通话 (CCP + ASCS + BAP)                         │
│  ├── 公共广播 (BASS + BAP - Auracast™)                   │
│  └── 助听辅助 (HAP + HAS + ASCS + BAP)                   │
├──────────────────────────────────────────────────────────┤
│  Profile 层                                              │
│  ├── CAP (Common Audio Profile) - 通用音频配置           │
│  │   ├── 定义 Initiator/Acceptor/Commander 角色          │
│  │   └── 规定 ASE 配置的标准流程                          │
│  ├── BAP (Basic Audio Profile) - 基础音频配置            │
│  │   ├── Unicast/Broadcast 角色定义                       │
│  │   └── 标准 QoS 配置 (低延迟/高质量/省电)               │
│  ├── MCP (Media Control Profile) - 媒体控制              │
│  │   └── 播放/暂停/曲目信息                               │
│  └── CCP (Call Control Profile) - 通话控制               │
│      └── 接听/挂断/保持                                   │
├──────────────────────────────────────────────────────────┤
│  Service 层                                              │
│  ├── ASCS (Audio Stream Control) - 音频流控制 ★          │
│  │   └── ASE 状态机 + CIS/BIS 管理                        │
│  ├── PACS (Published Audio Capabilities) - 音频能力发布  │
│  │   └── Sink/Source PAC + 音频位置 + 支持的 Contexts    │
│  ├── BASS (Broadcast Audio Scan) - 广播音频扫描          │
│  │   └── 广播码 (Broadcast_Code) 管理                     │
│  ├── VCS/VOCS/AICS - 音量控制                            │
│  └── CAS/CSIS/TMAS - 协调集/通用音频/电话媒体            │
├──────────────────────────────────────────────────────────┤
│  核心协议层                                               │
│  ├── GAP - 设备发现、连接、安全                           │
│  ├── GATT/ATT - 服务发现、特征读写                        │
│  ├── L2CAP - 信道复用                                     │
│  └── LE Isochronous Channels - CIS/BIS 传输              │
├──────────────────────────────────────────────────────────┤
│  控制器层                                                 │
│  ├── HCI - Host Controller Interface                     │
│  └── Link Layer - 射频、跳频、加密                       │
└──────────────────────────────────────────────────────────┘

6.2 ASCS 在协议栈中的位置

ASCS 处于承上启下的关键位置：

对上: 响应 BAP/CAP 的配置要求，将 Profile 层的音频需求转换为 ASE 操作
对下: 通过 ASE Control Point 命令驱动 CIS/BIS 的建立与释放
横向: 与 PACS 配合获取设备能力，与 MCP/CCP 配合响应内容控制

七、规范要点速查

7.1 ASCS v1.0.1 关键规范

|--------------------|------------------------------------|
| 项目 | 规范要求 |
| ASE 数量 | 至少支持 1 个 Sink ASE 或 1 个 Source ASE |
| 并发 ASE | 支持多个 ASE 同时处于 Streaming 状态 |
| Change Counter | 8-bit 无符号整数，溢出后从 0 重新开始 |
| Metadata 长度 | 最大 255 bytes |
| CIS 映射 | 一个 ASE 在 Streaming 状态时映射到一个 CIS |

7.2 BAP 标准 QoS 配置

BAP 规范定义了标准 QoS 配置，简化互操作性：

|------------------|----------|------------------|-------------|--------------------|-------------|
| 配置名称 | 应用场景 | SDU Interval | Max SDU | Retransmission | Latency |
| Low Latency | 游戏、通话 | 10ms | 60 bytes | 2 | 20ms |
| Balanced | 音乐、通用 | 10ms | 100 bytes | 2 | 40ms |
| High Quality | 高保真音乐 | 10ms | 155 bytes | 4 | 60ms |
| Gaming | 电竞 | 7.5ms | 45 bytes | 2 | 15ms |

7.3 错误码

|----------------------------|-------|-------------|
| Error Code | 值 | 说明 |
| ASE State Machine Error | 0x80 | ASE 状态机转换非法 |
| Invalid ASE ID | 0x81 | ASE_ID 不存在 |
| Invalid ASE State | 0x82 | 当前状态不支持此操作 |
| Invalid ASE Direction | 0x83 | ASE 方向不匹配 |
| Unsupported Audio Contexts | 0x84 | 不支持的音频上下文 |

八、总结

8.1 本 Trace 核心发现

场景: Pixel 7 手机通过 LE Audio Unicast 向车载多媒体/耳机传输音乐
应用 : 网易云音乐 / QQ音乐播放 "Way Back Into Love"
协议: ASCS + MCP + BAP + CAP 完整协议栈
音频: LC3 编码，~80kbps，10ms 帧长，40ms Presentation Delay
特性: 支持左右声道定位 (LEFT AUDIO LOCATION)，多流同步

8.2 ASCS 的核心价值

|-----------|-----------------|----------------------|
| 方面 | 经典蓝牙 (A2DP) | LE Audio (ASCS) |
| 连接 | 点对点 ACL | CIS 多流同步 |
| 延迟 | 100-200ms | <40ms |
| 功耗 | 较高 | 较低 (LC3 + 高效重传) |
| 多设备 | 复杂 (TWS 主从转发) | 原生支持 (独立 CIS) |
| 广播 | 不支持 | 支持 (BIS + Auracast™) |
| 上下文感知 | 无 | Metadata 传递上下文 |

8.3 后续分析建议

如需更深入的协议分析，建议：

导出文本日志 : 在 Ellisys 软件中将 .btt 导出为 .txt 或 .csv，可解析每个 ATT/HCI 包的详细信息
对比多设备: 捕获 TWS 耳机场景，观察左右耳 CIS 的同步策略
压力测试: 长时间播放时观察 ASE 状态是否稳定，是否存在异常 Releasing/重新 Enabling
与经典蓝牙对比: 同时捕获 A2DP 和 LE Audio，对比延迟和功耗

参考规范

ASCS v1.0.1 - Audio Stream Control Service (2024-10-01)
BAP v1.0.1 - Basic Audio Profile (2022-06-21)
CAP v1.0.1 - Common Audio Profile (2025-02-11)
Core Specification v6.2 - 蓝牙核心协议规范
MCP v1.0 - Media Control Profile

LE Audio ASCS 深度解析：从 BTSnoop 看音频流控制

一、Trace 概览

1.1 文件信息

1.2 捕获场景识别

1.3 涉及协议栈层级

二、ASCS 核心概念与规范解读

2.1 ASCS 是什么？

2.2 核心数据模型

2.3 ASE 状态机详解

2.4 ASCS 关键 Characteristics

2.5 ASE Control Point 操作码

三、从 BTSnoop 看 ASCS 实际工作流程

3.1 场景：Pixel 7 → 车载/耳机 媒体播放

Phase 1: 设备发现与能力交换 (GAP + PACS)

Phase 2: 服务发现 (GATT Discovery)

Phase 3: 编解码器配置 (Config Codec)

Phase 4: QoS 配置 (Config QoS)

Phase 5: 启用 ASE 与 CIS 建立

Phase 6: 音频流传输 (Streaming)

Phase 7: 媒体控制 (MCP)

3.2 ASCS 与 MCP 的协作关系

四、ASCS 关键机制深度分析

4.1 Change Counter 机制

4.2 Metadata 与音频上下文

4.3 CIS vs BIS：何时用什么？

4.4 Presentation Delay 与唇同步

五、BTSnoop 中的问题排查线索

5.1 常见问题模式

(1) ASE 状态机异常

(2) CIS 建立失败

(3) 音频断续/掉包

5.2 本 Trace 的健康检查

六、ASCS 与相关 Profile 的关系

6.1 完整 LE Audio 协议栈

6.2 ASCS 在协议栈中的位置

七、规范要点速查

7.1 ASCS v1.0.1 关键规范

7.2 BAP 标准 QoS 配置

7.3 错误码

八、总结

8.1 本 Trace 核心发现

8.2 ASCS 的核心价值

8.3 后续分析建议

3.1 场景：Pixel 7 → 车载/耳机媒体播放