Auracast 广播接收与发射

本文档介绍 Jieli iOS 蓝牙 SDK 生态中 Auracast（LE Audio 广播音频）的广播接收（Broadcast Receiver）与广播发射（Broadcast Source）机制，包括空口广播链路、接收同步流程、广播辅助（PAST）以及 iOS 平台的集成路径。

Purpose and Scope

本页聚焦 Auracast 这一一对多广播音频能力的端到端机制：

• 广播发射（Broadcast Source）：如何把一路音频流以 BIS（Broadcast Isochronous Stream）广播出去，供多个接收者同时收听。
• 广播接收（Broadcast Receiver）：如何扫描并同步周期广播（Periodic Advertising, PA），再同步 BIG 建立 BIS 数据接收。
• 广播辅助（Broadcast Assistant / PAST）：第三方设备如何把广播同步信息转发给接收者，帮助其"被动"接入广播。
• iOS 集成路径：在 iOS 平台上该能力通常如何分层实现、存在哪些平台限制。

留给相邻页面的内容：经典蓝牙连接、BLE 数据传输、一对一 LE Audio 通话（CIS）等能力属于本目录下其他核心功能页面，本页不做展开；若目录中存在对应页面，请参见相应条目。

源码探索声明：本次文档生成受源码探索预算限制（6 次工具调用），在仓库中未检索到文件名或内容直接包含 Auracast、Broadcast 等关键字的源文件。因此本文档以蓝牙 5.2+ LE Audio / Auracast 标准机制为主线，结合该 SDK 的通用分层给出架构与流程说明。文中标注 （标准概念） 的内容来自蓝牙规范；标注 （待确认） 的内容需要结合仓库内实际源码进一步核实，请勿将本文作为最终 API 依据。

Overview

Auracast 是蓝牙 5.2 LE Audio 引入的广播音频功能，其本质是把普通蓝牙"一对一"的音频链路扩展为"一对多"：一个发射设备（如电视、机场大屏）同时向无数个接收设备（如耳机、助听器）广播同一路音频。

核心概念（标准概念）

三个角色（标准概念）

1. 广播源（Broadcast Source）：编码（LC3）并广播音频，可设置广播名称、是否加密、BIS 数量等。
2. 广播接收器（Broadcast Receiver）：扫描 PA → 同步 BIG → 接收 BIS 数据 → 解码播放；用户通常通过二维码或 Broadcast ID 接入。
3. 广播辅助（Broadcast Assistant）：本身不收听，而是把从广播源获得的 PA 同步信息通过 PAST 转发给接收器，使接收器无需自行扫描即可接入。

为什么在 iOS 上需要依赖厂商 SDK（待确认）

iOS 的 Core Bluetooth 公开 API 并未直接暴露 LE Audio 的 ISO 等时信道；CBCentralManager 与 CBPeripheralManager 公开能力主要覆盖经典 BLE 广播/连接。因此 Auracast 广播接收与发射在 iOS 侧通常有两种实现路径：

1. 芯片厂商 SDK 指令通道：App 通过厂商 SDK（本仓库即 Jieli 的 iOS 蓝牙 SDK）向已连接的耳机/音箱等设备下发广播控制指令，由设备侧控制器完成 PA/BIG 的发射或接收（待确认，需在仓库源码中检索 JL_ManagerM 等管理器与指令封装）。
2. 系统私有/新版本 API：较新 iOS 版本逐步引入广播音频相关能力，公开程度与行为以 Apple 文档为准。

本文档后续架构图即按"应用层 → SDK 层 → 蓝牙控制器 → 空口"的分层来描述，这一分层是该类 SDK 的通用形态。

Architecture

下图给出 Auracast 广播接收与发射的整体架构：三个角色通过空口广播信道（PA/BIS）连接，iOS 侧 App 通过 SDK 与蓝牙控制器交互。

flowchart TD
    subgraph sg_Source["广播源（Broadcast Source）"]
        AppSrc["应用层（内容源 / 播放器）"]
        SdkSrc["蓝牙 SDK 层"]
        CtlSrc["蓝牙控制器（Controller）"]
        AppSrc --> SdkSrc --> CtlSrc
    end

    subgraph sg_Air["广播信道（BLE 5.2+ 空口）"]
        PA["周期广播 PA"]
        BIS["等时流 BIS / BIG"]
        PA --> BIS
    end

    subgraph sg_Receiver["广播接收端（Broadcast Receiver）"]
        CtlRcv["蓝牙控制器"]
        SdkRcv["蓝牙 SDK 层"]
        AppRcv["应用层（解码 / 播放）"]
        CtlRcv --> SdkRcv --> AppRcv
    end

    subgraph sg_Assistant["广播辅助（Broadcast Assistant）"]
        Asst["辅助接收设备"]
    end

    CtlSrc -->|"发射 PA 与 BIS"| PA
    BIS -->|"空口同步接收"| CtlRcv
    PA -.->|"监听 PA"| Asst
    Asst -.->|"PAST 转发同步信息"| CtlRcv

架构说明（节点均为标准角色/分层，非仓库内类名）：

• 广播源侧：应用层把音频内容交给 SDK 层，SDK 负责参数校验、BIG 描述生成并把创建广播组的指令下发到蓝牙控制器；控制器在空口开启 PA 并周期性发射 BIS 数据。
• 广播信道：PA 承载广播元信息（含 BIGInfo），BIS 承载实际音频数据；接收者必须先捕获 PA 才能知道何时、在哪个信道接收 BIS。
• 广播接收端：控制器捕获 PA 后按 BIGInfo 同步 BIG，BIS 数据流经 SDK 层回调给应用层解码播放。
• 广播辅助：辅助设备同样监听 PA，但通过 PAST 把同步信息转发给接收端，让接收端省去扫描过程、更快接入。

该架构的关键设计意图（标准概念）：把"发现广播"（PA）与"传输音频"（BIS）分离，使接收端可以在低功耗下先通过 PA 获取调度信息，再按需在精确时隙接收音频，从而支持大量接收者并发收听而互不干扰。

核心机制

广播发射（Broadcast Source）机制

广播发射的核心是把一路（或多路）LC3 编码音频封装进 BIG，并周期性广播 PA 宣告其存在。标准流程如下（标准概念，具体指令封装以仓库源码为准）：

1. 参数配置：应用层设置广播名称、Broadcast ID、加密方式（是否生成 Broadcast Code）、BIS 数量（单声道 1 路，立体声 2 路，可扩展更多）以及音频质量/LC3 码率。
2. BIG 描述生成：SDK 层根据上述参数生成 BIG 的调度描述（BIGInfo），包括 BIS 信道分配、传输时隙、加密信息等。
3. 开启 PA：控制器先启动周期广播，PA 事件中携带 BIGInfo，接收端凭此知道"音频在何时、以何种参数发射"。
4. 发射 BIS：在 BIG 的每个广播事件中按 BIS 信道依次发射音频数据包；多个 BIS 在时间上交错，避免同组内互相碰撞。
5. 状态回传：广播组的启动/停止/异常通过 SDK 回调上报应用层，应用层可展示二维码或分享 Broadcast ID 供他人接入。

设计意图：PA 与 BIS 分离使得发射端可以极低开销宣告广播存在（PA 不携带音频），同时 BIS 使用精确调度，接收端可以"睡眠到点再醒来"接收，这是实现海量并发听众的关键。

广播接收（Broadcast Receiver）机制

广播接收是一条"发现 → 同步 → 接收"的链路：

1. 扫描（Scanning）：接收端开启扫描，监听周围的周期广播；可通过 Broadcast ID 或广播名称过滤，只对目标 PA 建立同步。
2. 同步 PA（PA Sync）：捕获到目标 PA 后，接收端与 PA 建立同步，周期性唤醒读取 PA 数据，从中解析 BIGInfo。
3. 同步 BIG（BIG Sync）：按 BIGInfo 中的调度参数，接收端建立 BIG 同步，开始接收 BIS 数据包。
4. 解码播放：SDK 层将 BIS 数据按 LC3 解码（或透传原始帧给应用层），应用层完成播放。

接收端无需与发射端建立连接，这决定了 Auracast 的"开放收听"特性；加密广播则要求在接入时提供 Broadcast Code（通常由二维码或助听器 App 传递）。

广播辅助（Broadcast Assistant / PAST）机制

广播辅助解决"接收端自己没有扫描能力或想更快接入"的场景（标准概念）：

• 辅助设备（如手机）本身作为接收者监听 PA，或已通过其他方式获得广播同步信息；
• 辅助设备通过 PAST 将 PA 同步信息转发给目标接收端（如助听器）；
• 接收端收到同步信息后直接建立 PA/BIG 同步，无需自行扫描，从而省电并缩短接入时延。

在 iOS 生态中，手机作为"辅助 + 控制中心"是很自然的角色：手机扫码获取 Broadcast ID/Code，再通过 SDK 指令通道把参数下发给耳机/音箱端完成接收。

iOS 集成路径与分层

从工程角度看，Auracast 接收与发射在 App 侧通常按以下分层实现（待确认，需结合仓库源码核实类名与方法）：

flowchart LR
    subgraph sg_App["App 层"]
        UI["广播管理界面（扫码 / 列表 / 控制）"]
        Logic["广播业务逻辑（参数、状态机）"]
    end

    subgraph sg_Sdk["SDK 层（厂商蓝牙 SDK）"]
        Cmd["指令封装（创建 / 扫描 / 同步 / 停止）"]
        Callback["事件回调（状态 / 音频数据）"]
    end

    subgraph sg_Stack["系统与硬件"]
        CoreBT["CoreBluetooth / 私有通道"]
        Device["耳机 / 音箱（控制器侧 PA/BIS）"]
    end

    UI --> Logic
    Logic --> Cmd
    Cmd --> CoreBT
    CoreBT --> Device
    Device -->|"音频 / 状态"| Callback
    Callback --> Logic
    Logic --> UI

• App 层：负责广播 UI、用户扫码/输入 Broadcast Code、业务状态机。
• SDK 层：把业务请求封装为对设备/控制器的指令（创建广播组、开启扫描、BIG 同步等），并把设备上报的状态与音频数据以回调方式返回 App。
• 系统与硬件层：CoreBluetooth 提供连接与数据通道；PA/BIG/BIS 的实际空口行为由设备侧蓝牙控制器完成。

仓库内检索指引：由于本次探索预算内未命中 Auracast/Broadcast 关键字，建议后续在仓库中检索以下关键字定位实现：Auracast、Broadcast、LE_AUDIO、BIG、BIS、PAST，以及 Jieli SDK 常见的管理器/指令命名（如 JL_ManagerM、模型对象 JLModel_BT 中的 LE Audio 字段）。检索到的类与方法请以实际源码为准。

Core Flow

广播发射流程

sequenceDiagram
    participant App as 应用层 App
    participant SDK as 蓝牙 SDK 层
    participant Ctl as 蓝牙控制器
    participant Air as 空口（PA / BIS）

    App->>SDK: 配置广播参数（名称 / 加密 / BIS 数）
    SDK->>SDK: 校验参数并生成 BIG 描述
    SDK->>Ctl: 下发创建广播组指令
    Ctl->>Air: 开启周期广播 PA
    Air-->>Ctl: PA 已宣告（含 BIGInfo）
    Ctl-->>SDK: 广播组启动状态回调
    SDK-->>App: 启动成功（含 Broadcast ID）
    App->>App: 展示二维码 / 分享 Broadcast ID
    Ctl->>Air: 按 BIG 调度发射 BIS 音频流
    App->>SDK: 用户停止广播
    SDK->>Ctl: 停止广播组指令
    Ctl->>Air: 关闭 PA / 停止 BIS

逐步说明：发射链路的关键在于"先宣告、后发射"——PA 先于音频数据发出，且 PA 中携带 BIGInfo 让接收端能够精确对齐 BIS 时隙；停止时同样先停 BIS 再关 PA，避免接收端因残留调度信息空等。

广播接收流程

sequenceDiagram
    participant App as 应用层 App
    participant SDK as 蓝牙 SDK 层
    participant Ctl as 蓝牙控制器
    participant Air as 空口（PA / BIS）

    App->>SDK: 发起广播扫描（Broadcast ID / 名称过滤）
    SDK->>Ctl: 开启扫描
    Ctl->>Air: 监听周期广播 PA
    Air-->>Ctl: 捕获目标 PA（含 BIGInfo）
    Ctl->>Air: 同步 BIG / 建立 BIS 接收
    Air-->>Ctl: BIS 音频数据流
    Ctl-->>SDK: ISO 音频数据回调
    SDK-->>App: 解码后音频帧 / 事件回调
    App->>SDK: 用户停止收听 / 广播结束
    SDK->>Ctl: 停止 BIG 同步
    Ctl->>Air: 结束 BIS 接收

逐步说明：接收链路是发射链路的镜像——扫描阶段接收端可能持续监听大量 PA，因此通常用 Broadcast ID 或名称过滤以减少无效唤醒；同步成功后接收端只在 BIS 时隙唤醒收包，其余时间休眠，这是 Auracast 低功耗收听的核心。

接收端会话状态机

stateDiagram-v2
    [*] --> Idle
    Idle --> Scanning: 用户发起扫描
    Scanning --> Syncing: 捕获目标 PA（含 BIGInfo）
    Syncing --> Receiving: BIG 同步成功
    Receiving --> Receiving: 持续接收 BIS 音频
    Receiving --> Idle: 广播结束 / 用户停止
    Syncing --> Scanning: 同步失败 / 超时
    Scanning --> Idle: 用户取消

状态说明（标准概念，应用层状态机通常与之一致）：

• Idle：空闲，无广播活动。
• Scanning：扫描 PA，可能因超时或用户取消回到 Idle。
• Syncing：已捕获目标 PA，正在建立 BIG 同步；失败时回退到 Scanning 以便重试其他广播。
• Receiving：BIS 数据持续到达；广播结束、信号丢失或用户主动停止时回到 Idle。

该状态机把"发现"与"接收"拆成独立阶段，使任一阶段的失败都可局部重试而不影响整体会话——这是 Auracast 接收端设计的通用做法（标准概念，仓库内具体状态枚举与回调命名待确认）。

Usage Examples

No code example available（无可用代码示例）。

按照「绝不捏造代码示例」的约束：在本次源码探索预算内，未定位到仓库中与 Auracast 广播接收/发射直接相关的实现文件，因此无法提供经核实的代码片段。为避免误导，本文不展示任何未经源码验证的 API 调用。

如何在仓库中补充示例：请基于仓库实际代码检索以下关键字，并以真实源码为准补全本节：

• Auracast、Broadcast、LE_AUDIO、BIG、BIS、PAST（功能关键字）；
• Jieli SDK 常见入口（如 JL_ManagerM 管理器、JLModel_BT 模型、指令/回调封装类）中与广播相关的方法；
• 若检索到示例工程或 Demo，可摘录其"创建广播组 / 开启扫描 / 同步 BIG / 停止广播"的调用序列作为基本用法，并摘录状态回调处理作为进阶用法。

Configuration Options

以下为 Auracast 广播的标准概念参数（标准概念）。具体 SDK 配置项名称、类型与默认值需以仓库源码为准（待确认），本表仅用于帮助理解各参数的业务含义。

Failure Modes、边界与并发

以下分析基于 Auracast 标准机制（标准概念），仓库内具体错误码与重试策略待确认：

• 扫描不到目标广播：常见于 PA 间隔较长、扫描窗口不足或过滤条件错误。缓解方式：适当拉长扫描时间、放宽 Broadcast ID 过滤、在扫描与 PA 同步之间提供重试状态（见上文状态机 Scanning → Syncing → Scanning 回退）。
• BIG 同步失败/超时：信号弱或 BIGInfo 解析异常导致无法对齐时隙。设计上应支持从 Syncing 回退到 Scanning 重试，并向上层上报可读错误。
• 加密码错误：加密广播在 BIG 同步阶段校验 Broadcast Code，失败时应提示用户重新扫码/输入，不应无限重试以免功耗与体验恶化。
• 并发接收：BIG 支持多个接收端在同一广播组内各自同步，互不冲突；但接收端并发接入多个广播（如同时听两个 BIG）会显著增加功耗与实现复杂度，SDK 层通常限制为单活跃广播会话。
• 广播中断：发射端停止广播或移出覆盖范围后，接收端应检测 BIS 数据超时并回到 Idle，同时允许用户重新扫描。
• iOS 后台限制：App 进入后台后扫描与音频接收可能被系统挂起，需结合后台音频模式与系统策略设计（待确认，以系统行为与 SDK 说明为准）。

Performance 与运维考虑

• 功耗：Auracast 的低功耗收益来自"按 BIS 时隙唤醒"，扫描阶段反而是功耗高峰；建议用 Broadcast ID 预过滤、限制扫描持续时间。
• 时延：PA/BIG 间隔越小，接入与音频时延越低，但空口开销越大；发射端需在覆盖范围、并发听众与功耗之间权衡（标准概念）。
• 调试手段：开发阶段可通过日志打印 PA 捕获、BIG 同步成功、BIS 丢包率等关键事件定位问题；具体日志接口以仓库源码为准。
• 固件/协议版本：Auracast 依赖设备侧 LE Audio 固件支持，App 侧需在接入前检测设备能力（待确认，检索仓库中能力查询相关实现）。

Extension Points

• 参数扩展：广播参数（名称、加密、BIS 数）的配置入口是 SDK 指令封装的扩展点，业务方可在其上叠加自己的策略（如按场景切换广播配置）。
• 状态回调扩展：接收/发射状态机的事件回调是接入业务 UI 与统计的天然扩展点，可在回调中追加埋点、弹窗或自动重试逻辑。
• 二维码/分享集成：Broadcast ID 与 Broadcast Code 的生成、解析与分享（二维码、URL Scheme）通常由 App 层实现，可与现有账号/内容系统打通。
• 辅助接收（PAST）：若 SDK 支持 PAST，可扩展"手机作为广播辅助"的交互，如扫码后一键把广播推送到耳机端（待确认，需在源码中确认 PAST 支持情况）。

以上扩展点均以仓库实际暴露的接口为准，本文仅给出方向性指引。

Related Links

• iOS-JL_Bluetooth 仓库首页
• 仓库 main 分支文件浏览
• 相邻页面：本目录（4-core-features）下的其他核心功能页面，如经典蓝牙连接、BLE 数据传输、LE Audio 相关能力，请通过目录导航查看对应条目。
• 外部参考：Bluetooth SIG Auracast 规范与 LE Audio 规范（非仓库内容，仅作标准机制背景参考）。