LE Audio低功耗蓝牙音频详解 (三)

一苇以航322026-05-11 19:48

上一篇：LE Audio低功耗蓝牙音频详解 (二)

一、Generic Audio Framework

通用音频框架 (Generic Audio Framework, GAF) 是蓝牙低功耗音频 (LE Audio) 架构中的核心中间件。它定义了一套通用的服务和配置文件，用于在蓝牙设备之间进行音频数据的传输和控制，是实现跨设备互操作性的基础。

GAF 架构位于LE Audio 协议栈的中间层，基于如下底层核心规范提供的功能特性运行：

  • GAP (通用访问规范)：用于设备的连接、广播和同步。
  • GATT (通用属性配置文件)：采用Server/Client模式，用于配置音频流、关联内容（如媒体或电话）以及控制音量。
  • ISO (等时通道) ：音频流本身的传输载体，支持单播 （CIS）和 广播（BIS）两种模式。
  • LC3 编解码器：GAF 强制要求支持 LC3 (Low Complexity Communication Codec)，它能在低比特率下提供比传统 SBC 更高的音质。

GAF 包含多个子规范，负责不同的控制逻辑，关键配置文件与服务 (Profiles & Services)如下：

类别 配置文件 (Profile) 对应服务 (Service) 主要功能描述
流管理 BAP (基本音频规范) PACS/ASCS/ BASS 定义单播和广播流的建立、配置及能力发现。
音量控制 VCP (音量控制规范) VCS/VOCS/ AICS 控制音量大小、静音、音量偏移及音频输入切换。
媒体控制 MCP (媒体控制规范) MCS/GMCS 远程控制媒体播放器（播放、暂停、切歌、搜索等）。
通话控制 CCP (通话控制规范) TBS/GTBS 管理电话呼叫，支持多承载（如蜂窝网络与 VoIP）。
麦克风控制 MICP (麦克风控制规范) MICS 控制麦克风的静音、增益及输入选择。
设备协调 CSIP (协调集识别规范) CSIS 让多个设备（如左右耳塞）识别为一个协调集同步工作。
公共入口 CAP (通用音频规范) CAS 作为 GAF 的"胶囊"协议，协调上述各规范在复杂场景下的集成应用。

GAF支持的音频流模式规格：

  • 单播音频 (Unicast Audio)：基于连接的同步流 (CIS)，支持单向或双向传输，常用于手机与耳机间的私人通话或音乐播放。
  • 广播音频 (Broadcast Audio) ：基于无连接的同步流 (BIS)，支持单向传输，可实现 Auracast™ 广播，让无限数量的接收者同步收听同一音源。

GAF 之上还定义了针对特定场景的顶层规范，它们规定了如何组合使用 GAF 中的各项功能：

  • TMAP (电话与媒体音频规范)：定义智能手机、耳机、PC 等设备的通用通话和媒体交互。
  • HAP (助听规范)：专门针对助听器及其附件的互操作性设计。
  • PBP (公共广播规范)：用于机场、健身房等公共场所的 Auracast 广播标准。
  • GMAP (游戏音频规范)：针对游戏场景优化，提供极低延迟的音频传输。

GAF 主要是通过CAP将各个Profile串联起来实现的，接下来我们将对CAP进行详细的介绍。

二、Common Audio Profile Introduction

**通用音频规范（Common Audio Profile，CAP）**可视为GAF 框架中的核心规范，其在 GAF 框架中扮演着"指挥官"的角色，它通过调用 GAF 内的其他细分Profile（BAP/MCP/CCP等等）来实现完整的音频功能。 HAP、TMAP、GMAP和PBP等顶层Profile均通过CAP以及其他额外要求来实现。

本文涉及的发起方（Initiator）、接收方（Acceptor）和指挥方（Commander）三大角色均是在CAP中定义。尽管只有发起方和接收方能参与音频流传输，但CAP规定了所有角色如何整合通用音频框架规范中的组件组合。这些要求通过如下表格展示：

CAP（通用音频配置文件）在以下领域运行：

  • 采集与渲染控制：控制设备组中接收端的音频输入和音量
  • 音频流转换：在设备组上启动、更新和停止单播及广播音频流
  • 内容控制：媒体内容管理

在采集与渲染控制方面，CAP采用VCP、MICP 和CSIP 协议。 在音频流转换方面，CAP采用BAP 和CSIP 协议。 在内容控制方面，CAP采用MCP 和CCP 协议。 各角色间的关系如图2.1所示。

CAP 定义3 种核心角色，设备可并发实现：

角色 定位 典型设备
Acceptor 音频接收 / 渲染 / 采集端 耳机、音箱、麦克风、助听设备
Initiator 音频流发起 / 源端 手机、PC、电视、媒体播放器
Commander 音频控制端 遥控器、手机（协同控制）

本文会对CAP 规范中关于音频流的Start、Update、Stop、Handover等音频流转相关的procedures定义做详细的介绍。

三、Audio Stream Transition procedures

3.1 Unicast Audio Start procedure

Unicast Audio Start procedure（单播音频启动流程）：由 CAP Initiator（单播发起端） 发起，用于与 CAP Acceptor（单播接收端） 建立 Unicast Audio Stream（单播音频流） 、配置音频参数、启动 ISO 音频数据传输的标准化流程，核心依赖 ASE（Audio Stream Endpoint） 状态激活与 CIG（Connected Isochronous Group） 配置，实现一对一（或一组同步设备）的音频传输。

适用场景：手机与单副耳机建立音频连接、手机与多副同步耳机（同组）建立音频连接、设备重启后重新建立单播音频流等，是单播音频传输的基础启动流程。

核心参与角色：

  • CAP Initiator：单播发起端（如手机，BAP Unicast Client），核心发起方，负责发起连接、配置音频参数、创建 CIG、启动音频流传输，同步接收端状态。

  • CAP Acceptor：单播接收端（如耳机，BAP Unicast Server），接收发起端的启动请求，校验参数合法性、激活 ASE、同步 CIG 配置，接收并解码音频数据。

下图为一个完整的Unicast Audio Start Procedure流程图：

  1. 前置准备（Preparatory） ：CAP Acceptor 上电、耳机开盖或进入空闲可连接状态，发送 General Announcement（LE 广播），宣告自身为可连接的单播音频接收端，等待 Initiator 发现。

  2. 启动触发（Trigger）：CAP Initiator 检测到 Acceptors 的 General Announcement，或用户触发音频连接需求（如打开音乐、连接耳机），决定发起 Unicast Audio Start 流程。

  3. 建立 ACL 连接（ACL Connection） ：Initiator 进入 INAP（Initiator Non-Connected Audio Profile） 模式，扫描并与 Acceptor 建立 ACL（Asynchronous Connection-Oriented Link） 连接，为后续参数配置和音频传输提供基础链路。

  4. 能力上报与校验（Capability Reporting & Validation）：

    1. Acceptor 向 Initiator 上报 PACS（Published Audio Capabilities Service） 和 ASCS（Audio Stream Control Service） 状态，告知自身支持的音频特性、Contexts、QoS 能力；

    2. Initiator 校验 Acceptor 的能力，确认其支持待建立音频流的参数（如编码格式、Context 类型），校验通过则进入参数配置阶段，失败则终止流程。

  5. 参数配置（Configuration）：Initiator 依次配置单播音频流核心参数，确保参数与 Acceptor 能力匹配：

    1. 配置CIG_ID，创建 CIG 并分配唯一组号，若为多设备同步流，所有设备需分配同一 CIG_ID；

    2. 配置Presentation_Delay，统一多设备渲染延迟，保障同步播放；

    3. 配置 Streaming_Audio_Contexts，标记音频流场景（如 Media 音乐、Conversational 通话）；

    4. 配置 CCID_List，绑定音频流与 Initiator 内部的控制服务实例（如 MCS 媒体控制、TBS 通话控制）；

    5. 配置 QoS 参数（ISO 间隔、SDU 大小、传输优先级）及音频编码参数（如 LC3 码率）。

  6. 激活音频流（Enable ASE） ：Initiator 向 Acceptor 发送 BAP Unicast Enable ASE 指令，携带配置好的参数，请求激活 ASE 并启动音频流。

  7. 音频流启动（Stream Start）：

    1. Acceptor 接收指令后，再次校验参数合法性，激活自身 ASE，将 ASE 状态从 Idle 切换为 Streaming；

    2. Acceptor 向 Initiator 返回响应，确认 ASE 已激活；

    3. Initiator 启动 ISO 音频数据传输，通过 CIS 向 Acceptor 发送音频数据，Acceptor 接收、解码后播放。

  8. 状态同步（State Sync） ：Acceptor 向 Initiator 上报 ASCS: Notify (<<ASE>>, ASE_State=Streaming)，告知 Initiator 音频流已正常启动、播放；Initiator 确认状态后，维持音频传输。

  9. 流程结束（Completion）：单播音频流稳定传输，Initiator 与 Acceptor 维持 ASE_State=Streaming，Unicast Audio Start 流程完成，进入音频播放阶段。

3.2 Unicast Audio Update procedure

Unicast Audio Update Procedure（单播音频更新流程）：用于在已建立的 Unicast Audio Stream基础上，动态更新音频流参数、QoS 配置或上下文信息的标准化流程，不中断音频流传输（特殊场景可短暂暂停），核心依赖 ASE（Audio Stream Endpoint） 状态管理与参数重配置。

适用场景：音量调整、编码参数变更（如LC3码率）、QoS参数优化、Streaming_Audio_Contexts切换、CCID_List更新、Presentation_Delay调整等。

核心参与角色如下：

  • CAP Initiator：音频发起端（如手机，BAP Unicast Client），发起音频流更新请求，负责配置更新参数。

  • CAP Acceptor：音频接收端（如耳机，BAP Unicast Server），接收更新请求，校验参数合法性，执行更新并反馈结果。

如下为Unicast Audio Update Procedure的完整流程图：

  1. 更新触发（Trigger）：Initiator 检测到参数调整需求（如用户调音量、切换音频场景、网络状态变化），决定发起Unicast Audio Update。

  2. 参数配置（Configuration）：Initiator 配置待更新参数，可单独更新一项或多项，常见配置包括：

    1. QoS参数（ISO interval、SDU大小、CIG_ID调整）；

    2. 音频特性（LC3编码参数、声道数）；

    3. 元数据（Streaming_Audio_Contexts、CCID_List、Presentation_Delay）。

  3. 发送更新请求（Update Request） ：Initiator 向 Acceptor 发送 BAP Unicast Update ASE 指令，携带更新后的参数。

  4. 参数校验（Validation）：Acceptor 接收请求，校验参数合法性（如是否支持新的QoS、Context是否匹配Available Audio Contexts）。

  5. 执行更新（Execution）：

    1. 校验通过：Acceptor 执行参数更新，ASE状态可短暂切换为Configuring，不中断音频流（或短暂暂停后快速恢复）；

    2. 校验失败：Acceptor 拒绝更新，返回错误响应，维持原有参数与ASE_State=Streaming。

  6. 状态反馈（Confirmation） ：Acceptor 向 Initiator 发送响应，告知更新成功/失败；若成功，同步上报 ASCS: Notify (<<ASE>>, ASE_State=Streaming)。

  7. 更新生效（Effect）：更新成功后，Initiator 与 Acceptor 按新参数传输音频流，流程结束。

3.3 Unicast Audio Stop procedure

Unicast Audio Stop Procedure（单播音频停止流程）：在用于主动终止已建立的 Unicast Audio Stream（单播音频流），释放 ASE 资源、终止 ISO 音频数据传输的标准化流程，核心是将 ASE 状态从 Streaming 切换为 Idle，同步释放相关 QoS 与控制绑定资源。

适用场景：停止播放音频、耳机断开连接、设备低电量、切换音频输出设备、主动终止音频流等。

核心参与角色：

  • CAP Initiator：音频发起端（如手机，BAP Unicast Client），可主动发起音频流停止请求；也可接收 Acceptor 发起的停止请求并确认。

  • CAP Acceptor：音频接收端（如耳机，BAP Unicast Server），可主动发起停止请求（如低电量、断开连接）；也可接收 Initiator 的停止指令，执行停止操作并反馈。

如下为Unicast Audio Stop Procedure的完整流程图：

  1. 停止触发（Trigger）：触发源分为两种（规范支持双向触发）：

    1. Initiator 触发：用户停止播放、切换输出设备、主动终止流；

    2. Acceptor 触发：耳机低电量、断开连接、异常故障，需终止流。

  2. 发送停止请求（Stop Request）：

    1. Initiator 触发：向 Acceptor 发送 BAP Unicast Disable ASE 指令，请求终止音频流；

    2. Acceptor 触发：向 Initiator 发送 ASCS: Notify (<<ASE>>, ASE_State=Stopping)，发起停止请求。

  3. 停止确认（Confirmation）：接收请求的一方（Acceptor/Initiator）确认停止需求，准备执行停止操作，反馈确认响应。

  4. 执行停止（Execution）：

    1. 终止 ISO 音频数据传输，停止发送/接收音频流；

    2. 将 ASE 状态从 Streaming 切换为 Idle，释放 ASE 相关资源；

    3. 解除 CCID_List 与控制服务的绑定，释放 QoS 配置、CIG 相关资源。

  5. 状态同步（State Sync） ：Acceptor 向 Initiator 上报 ASCS: Notify (<<ASE>>, ASE_State=Idle)，告知流已完全停止、资源已释放。

  6. 流程结束（Completion）：Initiator 确认 ASE 状态为 Idle，Unicast Audio Stream 正式终止，可执行后续操作（如断开 ACL 连接、进入待机状态）。

3.4 Broadcast Audio Start procedure

Broadcast Audio Start procedure（广播音频启动流程）：由 Broadcast Source（广播源） 发起，用于建立 Broadcast Audio Stream（广播音频流） ，向多个 Broadcast Sink（广播接收端） 同步传输音频数据的标准化流程，核心依赖BIG（Broadcast Isochronous Group） 管理与广播信道配置，支持多设备同时接收同一音频流。

适用场景：多副耳机同步接收同一音频（如多人共享音乐、会议广播）、公共场景音频推送（如商场、展馆）等，无需与接收端单独建立ACL连接。

核心参与角色：

  • CAP Commander/Broadcast Source：广播源（如手机、音响，BAP Broadcast Source），发起广播音频流，配置BIG参数、音频特性，负责发送ISO广播音频数据。

  • CAP Acceptor/Broadcast Sink：广播接收端（如耳机，BAP Broadcast Sink），扫描并同步广播源的BIG信息，接收广播音频流，解码后播放。

  • Broadcast Assistant（可选）：辅助设备，用于向Broadcast Sink传递BIG配置信息（如加密参数、QoS参数），简化接收端同步流程。

如下为Broadcast Audio Start Procedure的完整流程图：

  1. 广播触发（Trigger）：Broadcast Source 检测到广播需求（如用户开启多设备共享音频），进入广播模式，准备发起 Broadcast Audio Start 流程。

  2. BIG 与参数配置（Configuration）：

    • 广播源创建 BIG ，分配唯一 BIG_ID，配置BIG参数（ISO间隔、SDU大小、广播信道）；

    • 配置音频特性（LC3编码参数、声道数）与元数据（Streaming_Audio_Contexts、Presentation_Delay）；

    • （可选）通过Broadcast Assistant 向潜在接收端传递BIG配置与加密信息（若启用加密）。

  3. 发送广播公告（Broadcast Announcement） ：广播源通过 LE 扩展广播发送 Broadcast Announcement，携带BIG_ID、音频特性、QoS参数，告知周围设备"可接收广播音频流"。

  4. 接收端扫描与同步（Sink Scan & Sync）：

    • Broadcast Sink 扫描到广播公告，解析BIG参数与音频信息；

    • 接收端同步广播源的BIG时序，建立与BIG的同步关系，准备接收BIS音频流；

    • （若加密）接收端通过配置信息完成解密初始化。

  5. 启动广播传输（Start Broadcast Transmission）：广播源启动ISO广播传输，通过BIS发送音频数据；接收端同步接收BIS数据，解码后进入播放状态。

  6. 状态同步（State Sync）：

    • 广播源：ASE状态从Idle切换为Streaming，维持广播传输；

    • 接收端：ASE状态从Idle切换为Streaming，同步上报 ASCS: Notify (<<ASE>>, ASE_State=Streaming)，确认接收正常。

  7. 流程结束（Completion）：广播音频流稳定传输，所有同步成功的接收端正常播放音频，Broadcast Audio Start 流程完成。

3.5 Broadcast Audio Update procedure

Broadcast Audio Update Procedure（广播音频更新流程）：由 Broadcast Source（广播源） 发起，用于在已建立的 Broadcast Audio Stream（广播音频流） 基础上，动态更新 BIG（Broadcast Isochronous Group） 参数、音频特性、QoS 配置或元数据的标准化流程，核心是同步所有已接入的 Broadcast Sink（广播接收端） 完成参数更新，尽可能不中断广播音频传输。

适用场景：广播音频音量调整、LC3编码参数变更、BIG时序优化、Presentation_Delay调整、Streaming_Audio_Contexts切换、加密参数更新等。

核心参与角色：

  • CAP Commander/Broadcast Source：广播源（如手机、音响，BAP Broadcast Source），发起广播音频更新请求，配置更新参数，同步通知所有接收端，负责执行更新并确认同步结果。

  • CAP Acceptor/Broadcast Sink：广播接收端（如耳机，BAP Broadcast Sink），接收广播源的更新通知，校验参数合法性，执行参数更新，反馈更新状态。

  • Broadcast Assistant（可选）：辅助设备，协助广播源向未同步的接收端传递更新后的BIG配置、加密参数等信息，提升同步效率。

如下为Broadcast Audio Update Procedure的完整流程图：

  1. 更新触发（Trigger）：Broadcast Source 检测到更新需求（如用户调整广播音量、网络状态变化、音频场景切换），决定发起Broadcast Audio Update流程。

  2. 更新参数配置（Configuration）：

    1. 广播源配置待更新参数，可单独更新一项或多项，常见配置包括：BIG参数（ISO间隔、SDU大小）、音频特性（LC3码率、声道数）、元数据（Streaming_Audio_Contexts、Presentation_Delay）、加密参数（若启用）；

    2. 确保更新后的参数符合CAP/BAP规范，且与所有已接入的Broadcast Sink的能力匹配。

  3. 发送更新通知（Update Notification） ：广播源通过 LE 扩展广播发送 Broadcast Update Announcement，携带更新后的BIG参数、音频信息及更新生效时间，通知所有已接入和潜在的接收端。

  4. 接收端参数校验与同步（Sink Validation & Sync）：

    1. 已接入的Broadcast Sink 接收更新通知，解析更新参数，校验自身是否支持该参数（如是否兼容新的QoS、Context是否匹配）；

    2. 校验通过：接收端同步更新自身参数，ASE状态可短暂切换为Configuring，不中断音频接收；

    3. 校验失败：接收端拒绝更新，维持原有参数，向广播源反馈更新失败响应，继续接收原有广播音频流。

  5. 更新生效（Effect）：到达更新生效时间后，广播源按新参数发送广播音频数据；所有校验通过的接收端按新参数接收、解码、播放音频。

  6. 状态同步（State Sync）：

    1. 广播源：ASE状态从Configuring（若切换）恢复为Streaming，维持新参数下的广播传输；

    2. 接收端：更新成功后，ASE状态恢复为Streaming，向广播源上报 ASCS: Notify (<<ASE>>, ASE_State=Streaming)，确认更新生效；更新失败的接收端维持原有状态，反馈失败信息。

  7. 流程结束（Completion）：所有接收端完成参数同步（或反馈失败），广播音频流按新参数稳定传输，Broadcast Audio Update流程完成；对于更新失败的接收端，广播源可选择重试更新或允许其继续接收原有流。

3.6 Broadcast Audio Stop procedure

Broadcast Audio Stop procedure（广播音频停止流程）：由 Broadcast Source（广播源） 主动发起，或由 Broadcast Sink（广播接收端） 主动退出，用于终止已建立的 Broadcast Audio Stream（广播音频流） 、释放 BIG（Broadcast Isochronous Group） 资源、终止 ISO 广播音频数据传输的标准化流程，核心是同步所有相关设备完成资源释放，确保广播流有序终止。

适用场景：用户停止广播播放、广播源低电量、切换音频输出模式、广播源主动终止广播、Broadcast Sink 主动退出广播组、异常故障导致的广播终止等。

核心参与角色：

  • CAP Commander/Broadcast Source：广播源（如手机、音响，BAP Broadcast Source），核心发起方，负责发送广播停止通知、终止 BIS 音频传输、释放 BIG 资源，同步所有接收端的停止状态。

  • CAP Acceptor/Broadcast Sink：广播接收端（如耳机，BAP Broadcast Sink），接收广播停止通知，或主动发起退出请求，终止音频接收、释放自身 ASE 资源，切换 ASE 状态并反馈停止结果。

  • Broadcast Assistant（可选）：辅助设备，协助广播源向未及时接收停止通知的 Broadcast Sink 传递停止指令，确保所有接收端同步完成停止操作，避免资源泄漏。

如下为Broadcast Audio Stop Procedure的完整流程图：

  1. 停止触发（Trigger）：触发源分为两种（规范支持双向触发，核心以广播源发起为主）：

    1. Broadcast Source 触发：用户停止广播播放、广播源低电量、主动终止广播、切换音频模式等；

    2. Broadcast Sink 触发：接收端主动退出广播组、低电量、异常故障，向广播源发起退出请求。

  2. 发送停止通知（Stop Notification）：

    1. 广播源触发：向所有已接入及潜在的接收端发送 Broadcast Stop Announcement，携带 BIG_ID、停止生效时间，告知广播即将终止；

    2. 接收端触发：向广播源发送 ASCS: Notify (<<ASE>>, ASE_State=Stopping)，发起退出广播组请求，等待广播源确认。

  3. 停止确认（Confirmation）：

    1. 广播源触发：接收端接收停止通知后，校验 BIG_ID 匹配性，反馈确认响应，准备执行停止操作；

    2. 接收端触发：广播源接收退出请求后，反馈确认响应，通知接收端可执行退出操作，并同步更新广播组状态。

  4. 执行停止操作（Execution）：

    1. Broadcast Source：到达停止生效时间，终止 BIS 音频数据传输，释放 BIG 资源（ISO 时隙、广播信道），将自身 ASE 状态从 Streaming 切换为 Idle；

    2. Broadcast Sink：接收确认后，终止音频接收与解码，释放自身 ASE 资源，将 ASE 状态从 Streaming 切换为 Idle，解除与 BIG 的同步关系；

    3. （可选）Broadcast Assistant：向未接收停止通知的接收端传递停止指令，确保所有接收端同步停止。

  5. 状态同步（State Sync）：

    1. Broadcast Sink：停止完成后，向广播源上报 ASCS: Notify (<<ASE>>, ASE_State=Idle)，告知自身已完成停止、资源已释放；

    2. Broadcast Source：接收所有接收端的状态反馈，确认所有关联设备均已停止，完成 BIG 资源的最终释放。

  6. 流程结束（Completion）：广播源完全释放 BIG 资源，所有接收端 ASE 状态均为 Idle，Broadcast Audio Stream 正式终止；广播源可进入待机状态，接收端可重新扫描其他广播或进入低功耗模式。

3.7 Broadcast AudioReception Start procedure

Broadcast Audio Reception Start（广播音频接收启动流程）：由 Broadcast Sink 发起，用于扫描、发现 Broadcast Source 发送的 Broadcast Announcement，同步 BIG 时序、激活 ASE、完成音频接收与播放的标准化基础流程，是广播音频接收的前置核心操作，所有广播接收均需先执行该启动流程。

适用场景：耳机上电后接入广播、设备重启后重新启动广播接收、接收端从低功耗模式唤醒后启动接收、首次接入某一广播源等基础场景。

核心参与角色：

  • CAP Commander/Broadcast Sink：核心执行方（如耳机，BAP Broadcast Sink），负责启动扫描、解析广播参数、同步 BIG、激活 ASE、接收并播放音频。

  • CAP Acceptor/Broadcast Source ：被动协同方（如手机、音响，BAP Broadcast Source），持续发送 Broadcast Announcement 和 BIS（Broadcast Isochronous Stream） 音频数据，为接收端启动提供同步与数据支撑。

  • Broadcast Assistant（可选）：辅助方，传递 BIG 配置信息（如加密参数），简化接收端同步流程，提升启动效率。

如下为Broadcast Audio Reception Start Procedure的完整流程图：

  1. 接收端准备：Broadcast Sink 上电、进入可接收状态，启动 LE 广播扫描功能，搜索周围的 Broadcast Announcement。

  2. 扫描与发现：接收端扫描到 Broadcast Announcement，解析公告中的核心参数（BIG_ID、音频编码、QoS、Streaming_Audio_Contexts），判断自身兼容性。

  3. 参数校验：校验自身是否支持公告中的编码格式、QoS 参数、Context 类型，校验通过进入同步阶段，失败则继续扫描其他广播。

  4. BIG 时序同步：根据解析的 BIG 参数，与广播源的 BIG 时序建立同步关系，校准时钟，确保与 ISO 时隙同步；加密场景下，通过 Broadcast Assistant 获取密钥，完成解密初始化。

  5. ASE 激活：接收端激活自身 ASE，将 ASE 状态从 Idle 切换为 Streaming，准备接收 BIS 音频数据。

  6. 音频接收与播放：同步接收 BIS 音频数据，通过内置解码器解码，按 Presentation_Delay 配置延迟播放，确保音频流畅。

  7. 状态同步 ：向广播源上报 ASCS: Notify (<<ASE>>, ASE_State=Streaming)，告知启动完成、接收正常。

  8. 启动完成：接收端维持 Streaming 状态，稳定接收播放，启动流程结束，进入持续接收阶段。

3.8 Broadcast AudioReception Stop procedure

Broadcast Audio Reception Stop（广播音频接收停止流程）：基于启动流程，由 Broadcast Sink 主动发起或被动触发，用于终止广播音频接收、释放 ASE 与 BIG 同步资源、切换 ASE 状态的标准化进阶流程，包含主动退出、异常停止、广播源终止触发三种场景，确保接收流程有序终止、资源不泄漏。

适用场景：用户主动退出广播、接收端低电量、BIG 同步丢失（异常停止）、广播源终止广播、切换至其他广播源等进阶场景。

核心参与角色：

  • Broadcast Sink：核心执行方，负责发起停止请求、终止接收、释放资源、切换 ASE 状态，反馈停止结果。

  • Broadcast Source：协同方，接收停止通知、终止对应 BIS 传输（若自身终止广播），确认接收端停止状态。

  • Broadcast Assistant（可选）：辅助方，传递广播源终止通知、异常停止参数，协助接收端完成停止操作。

如下为Broadast Audio Reception Stop Procedure 的完整流程图：

  1. 停止触发：触发源分为三类，对应不同场景：

    1. 主动触发：用户操作退出广播、接收端低电量，主动发起停止请求；

    2. 异常触发：接收端检测到 BIG Sync Loss、信号中断、解码失败，自动触发停止；

    3. 被动触发：接收端扫描到广播源发送的 Broadcast Stop Announcement，被动启动停止。

  2. 停止请求/确认：

    1. 主动触发：接收端向广播源发送停止通知，切换 ASE 状态为 Stopping，等待广播源确认；

    2. 被动触发：接收端解析 Broadcast Stop Announcement，无需请求，直接进入停止执行阶段；

    3. 异常触发：接收端切换 ASE 状态为 Sync Loss，向广播源上报 ASCS: Notify (Sync Loss)，直接执行停止。

  3. 停止执行：

    1. 终止 BIS 音频数据接收与解码，停止播放；

    2. 释放 BIG 同步资源，解除与广播源的时序同步关系；

    3. 释放 ASE 资源，将 ASE 状态从 Stopping/Sync Loss 切换为 Idle。

  4. 状态同步 ：接收端向广播源上报 ASCS: Notify (<<ASE>>, ASE_State=Idle)，告知停止完成、资源已释放。

  5. 停止完成：接收端停止广播扫描，进入低功耗或待机状态；广播源确认所有接收端停止后，释放对应 BIG 资源，停止流程结束。

3.9 Unicast to Broadcast Audio Handover procedure

Unicast to Broadcast Audio Handover procedure：由 Broadcast Sink 主动发起或被动触发，将当前接收的 CIS（Connected Isochronous Stream） 单播音频流，切换至BIS（Broadcast Isochronous Stream） 广播音频流的标准化操作流程。核心动作包括：终止单播连接与资源释放、扫描发现广播源、同步广播 BIG 参数、激活广播接收 ASE，全程遵循 CAP/BAP 规范，适配基础应用场景，不涉及复杂异常处理与跨区域切换。适用场景如下：

  • 用户手动触发切换：如耳机从连接手机单播（播放本地音乐），切换至接收周边广播音频（如公共广播、设备广播）；

  • 单播连接异常触发：单播信号中断、单播源低电量终止传输，接收端自动切换至预设广播源；

  • 场景需求触发：接收端进入广播覆盖区域，自动切换至广播音频（如耳机进入商场，切换至商场公共广播）。

核心参与角色：

  • Broadcast Sink：核心执行方（如耳机，BAP Broadcast Sink/BAP Unicast Server），负责发起切换、终止单播连接、扫描广播源、同步广播参数、激活广播接收。

  • CAP Initiator ：原单播发起端（如手机，BAP Unicast Client），协同终止单播 CIS 传输、释放 CIG（Connected Isochronous Group） 资源，确认切换状态。

  • Broadcast Source ：目标广播源（如公共广播设备、手机广播端，BAP Broadcast Source），持续发送 Broadcast Announcement 和 BIS 音频数据，为接收端提供同步与数据支撑。

  • Broadcast Assistant（可选）：辅助方，传递广播源 BIG 配置参数，协助接收端快速完成同步，缩短切换延迟。

下图为Unicast to Broadcast Audio Handover完整的流程图：

  1. 切换触发：接收端触发切换信号（用户手动操作、单播信号中断、单播源终止），确认切换至广播音频流。

  2. 切换准备：

    1. 接收端向 CAP Initiator（原单播源）上报 ASCS: Notify (Handover Initiated)，告知即将从单播切换至广播；

    2. 接收端启动广播扫描功能，搜索周围目标 Broadcast Source 发送的 Broadcast Announcement；

    3. 解析广播公告中的核心参数（BIG_ID、QoS、音频编码），校验自身兼容性，确认支持目标广播参数后进入下一步。

  3. 单播连接终止：

    1. 接收端切换 ASE 状态为 Stopping，终止单播 CIS 音频数据的接收、解码与播放；

    2. 释放单播相关资源（ACL 连接、CIG 同步资源、ASE 单播配置）；

    3. 向 CAP Initiator 上报ASCS: Notify (Stopping)，CAP Initiator 确认后终止 CIS 传输、释放 CIG 资源。

  4. 广播参数同步：

    1. 接收端切换 ASE 状态为 Configuring，根据解析的 BIG 参数，与 Broadcast Source 的 BIG 时序建立同步关系，校准时钟；

    2. （可选）加密场景下，通过 Broadcast Assistant 获取广播加密密钥，完成解密初始化；

    3. 同步广播的 Presentation_Delay（渲染延迟），确保广播播放时序正常。

  5. 广播接收激活：接收端激活广播接收 ASE，将状态从 Configuring 切换为 Streaming，开始接收 Broadcast Source 发送的 BIS 音频数据，解码后播放。

  6. 状态同步与确认 ：接收端向 Broadcast Source 上报 ASCS: Notify (<<ASE>>, ASE_State=Streaming)，告知广播接收激活成功；同时向 CAP Initiator 上报切换完成通知。

  7. 切换完成：接收端稳定接收、播放广播音频，维持 Streaming 状态；原单播源完全释放资源，切换流程结束。

3.10 Broadcast to Unicast Audio Handover procedure

Broadcast to Unicast Audio Handover procedure：由 Broadcast Sink 主动发起或被动触发，将当前接收的 BIS（Broadcast Isochronous Stream） 广播音频流，切换至 CIS（Connected Isochronous Stream） 单播音频流的标准化操作流程。核心动作包括：终止广播接收与资源释放、建立单播 ACL 连接、配置单播参数、激活单播接收 ASE，全程遵循 CAP/BAP 规范，适配基础应用场景，不涉及复杂异常处理与跨区域切换。适用场景：

  • 用户手动触发切换：如耳机从接收公共广播，切换至连接手机单播（播放本地音乐、接听通话）；

  • 广播连接异常触发：广播信号中断、广播源终止传输，接收端自动切换至预设单播源；

  • 场景需求触发：接收端离开广播覆盖区域，自动切换至已配对的单播设备（如耳机离开商场，切换回手机单播）

核心参与角色：

  • Broadcast Sink：核心执行方（如耳机，BAP Broadcast Sink/BAP Unicast Server），负责发起切换、终止广播接收、建立单播连接、配置单播参数、激活单播接收。

  • Broadcast Source ：原广播源（如公共广播设备、手机广播端，BAP Broadcast Source），协同终止 BIS 传输、释放 BIG（Broadcast Isochronous Group） 资源，确认切换状态。

  • CAP Initiator ：目标单播发起端（如手机，BAP Unicast Client），协同建立 ACL（Asynchronous Connection-Oriented Link） 连接、配置 CIG（Connected Isochronous Group） 参数，发送 CIS 单播音频数据。

  • Broadcast Assistant（可选）：辅助方，传递单播源配置参数，协助接收端快速建立单播连接，缩短切换延迟。

下图为Broadcast to Unicast Audio Handover的完整流程图：

  1. 切换触发：接收端触发切换信号（用户手动操作、广播信号中断、广播源终止），确认切换至单播音频流。

  2. 切换准备：

    1. 接收端向 Broadcast Source（原广播源）上报 ASCS: Notify (Handover Initiated)，告知即将从广播切换至单播；

    2. 接收端停止广播扫描，发起与目标 CAP Initiator（单播源）的 ACL 连接请求；

    3. CAP Initiator 确认连接请求，与接收端建立 ACL 连接，为后续单播参数配置提供基础链路。

  3. 广播接收终止：

    1. 接收端切换 ASE 状态为 Stopping，终止广播 BIS 音频数据的接收、解码与播放；

    2. 释放广播相关资源（BIG 同步资源、ASE 广播配置）；

    3. 向 Broadcast Source 上报 ASCS: Notify (Stopping)，Broadcast Source 确认后终止 BIS 传输、释放 BIG 资源。

  4. 单播参数配置：

    1. 接收端切换 ASE 状态为 Configuring，与 CAP Initiator 协同配置单播核心参数（CIG_ID、QoS 参数、音频编码、Presentation_Delay）；

    2. （可选）加密场景下，接收端与 CAP Initiator 完成单播加密密钥协商，确保 CIS 数据安全传输；

    3. CAP Initiator 配置 CIS 传输参数，建立 CIG 同步关系，准备发送单播音频数据。

  5. 单播接收激活：接收端激活单播接收 ASE，将状态从 Configuring 切换为 Streaming，准备接收 CAP Initiator 发送的 CIS 音频数据。

  6. 状态同步与确认 ：接收端向 CAP Initiator 上报 ASCS: Notify (<<ASE>>, ASE_State=Streaming)，告知单播接收激活成功；同时向 Broadcast Source 上报切换完成通知。

  7. 切换完成：CAP Initiator 发送 CIS 单播音频数据，接收端解码后播放，维持 Streaming 状态；原广播源完全释放资源，切换流程结束。

3.11 Distribute Broadcast_Code procedure

Distribute Broadcast_Code procedures：由 Broadcast Source 发起，用于生成、分发 Broadcast_Code（广播码），并由 Broadcast Sink 接收、校验的标准化流程。Broadcast_Code 是一串唯一标识广播源或广播组的加密/身份验证码，核心作用是保障广播音频传输安全（加密解密密钥关联）、区分不同广播组、验证接收端接入权限，流程适配基础分发场景，不涉及复杂密钥协商与多设备批量分发的进阶操作。适用场景：

  • 加密广播场景：广播源生成 Broadcast_Code，分发给授权接收端，用于广播音频（BIS）的加密解密，防止未授权设备接收；

  • 广播组区分场景：同一区域存在多个广播源时，通过不同 Broadcast_Code 区分广播组，接收端通过校验对应广播码接入目标广播；

  • 权限验证场景：广播源通过分发 Broadcast_Code，限制仅授权接收端可接入，未获取广播码的设备无法同步 BIG 时序、接收广播音频。

核心参与的角色：

  • Broadcast Source：核心发起方（如手机、公共广播设备，BAP Broadcast Source），负责生成唯一 Broadcast_Code、指定分发链路、发送广播码，验证接收端校验结果。

  • Broadcast Sink：核心接收方（如耳机，BAP Broadcast Sink），负责接收 Broadcast_Code、完成校验，校验通过后用于广播接入或加密解密。

  • Broadcast Assistant（可选）：辅助分发方，用于广播码的间接分发（如手机作为辅助设备，将广播源的 Broadcast_Code 转发给耳机），适用于接收端无法直接从广播源获取广播码的场景。

下图为Distribute Broadcast_Code procedures的完整流程图：

  1. 广播码生成：Broadcast Source 基于自身标识、广播组信息，生成唯一的 Broadcast_Code，关联当前广播的 BIG_ID 与加密参数（若为加密场景），确保广播码唯一性与安全性。

  2. 分发准备：

    1. 广播源确定分发链路（基础场景优先复用广播链路），将 Broadcast_Code 封装为符合广播传输规范的帧结构；

    2. （可选）若接收端无法直接接收广播链路消息，广播源将 Broadcast_Code 发送至 Broadcast Assistant，由其转发。

  3. 广播码分发：

    1. 广播链路分发：广播源通过 Broadcast Announcement 信道，将封装后的 Broadcast_Code 以广播形式发送；

    2. （可选）辅助链路分发：Broadcast Assistant 接收广播源发送的 Broadcast_Code，通过点对点链路转发给目标 Broadcast Sink。

  4. 广播码接收：Broadcast Sink 监听对应分发链路，捕获 Broadcast_Code 数据，完成数据接收与帧解析，提取完整的 Broadcast_Code 与关联的 BIG_ID。

  5. 广播码校验：

    1. 接收端校验广播码的合法性（与广播源标识、目标 BIG_ID 匹配）、完整性（无数据丢失或篡改）；

    2. 校验通过：进入广播接入准备（同步 BIG 时序）；校验失败：丢弃广播码，继续监听或触发重试接收。

  6. 校验结果上报 ：接收端通过 ASCS 向广播源上报校验结果，发送 ASCS: Notify (Broadcast_Code_Validated, Result=Success/Failure)，复用广播同步链路传输，无需 ACL 连接。

  7. 流程完成：

    1. 校验成功：接收端使用 Broadcast_Code 完成加密解密初始化（加密场景），同步 BIG 时序，准备接收 BIS 广播音频；

    2. 校验失败：广播源可重新分发广播码，或拒绝该接收端接入，流程终止。

相关推荐
a里啊里啊4 小时前
软考-软件评测师：知识点整理（九）——其他杂项
音视频
苏州汇成元电子科技6 小时前
为什么越来越多AI设备开始使用I-PEX 81463-100B-02-D 30Pin极细同轴线束？
人工智能·音视频·硬件工程·信号处理·材料工程
ZC跨境爬虫7 小时前
跟着 MDN 学 HTML day_36：（深入理解 Comment 接口与 DOM 注释节点）
前端·javascript·ui·html·音视频·视频编解码
reasonsummer9 小时前
【教学类-160-25】20260507 AI视频培训-练习025“豆包AI视频《一日生活》+豆包图片风格：二次元
音视频·豆包
LCG元11 小时前
STM32实战：基于STM32F407的FFT频谱分析（音频信号处理）
stm32·音视频·信号处理
小何开发12 小时前
ffmpeg 安装与使用: 将视频分片与组装
ffmpeg·音视频
EasyDSS12 小时前
私有化视频会议系统/智能会议管理系统EasyDSS打造全场景音视频协作新生态
音视频
淘小白_TXB219612 小时前
微博图文视频批量采集软件用户手册
音视频
ZC跨境爬虫14 小时前
跟着 MDN 学 HTML day_37：（深入掌握 CustomEvent 自定义事件接口）
前端·javascript·ui·html·音视频
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03零基础教你claude code 接入 deepseek V404CC-Switch & Claude 基于 Linux 服务器安装使用指南05【AI】2026 年具身智能模型和世界模型总结06要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法07Windows端Codex接入第三方模型（DeekSeek，BaiLian)08裂开！ChatGPT 居然开始要手机号验证，附详细解决方法09Cursor 接入 DeepSeek‑V4‑Pro 完整指南（2026 实测）10codex app每次打开重连5次Reconnecting问题解决