【LE Audio】BAP协议精讲[7]: Broadcast Sink规范拆解与实战指南

在蓝牙LE广播音频生态中，Broadcast Sink（广播宿）是最终的音频消费终端——小到真无线耳机接收商场背景音乐，大到智能音箱同步电视多语言音频，所有一对多的无线音频接收场景，都离不开Broadcast Sink的规范实现。它不仅要能稳定接收广播音频流，还要通过标准化的能力公示、传输适配，确保与不同厂商的Broadcast Source（广播源）无缝兼容。本文基于BAP规范的核心要求，从服务部署、传输适配、音频能力、上下文支持到厂商自定义，全方位拆解Broadcast Sink的核心规范，搞懂接收端如何合规、高效地承接广播音频。

目录

一、核心定位：Broadcast Sink是什么？

二、核心服务部署：必选PACS服务的底层逻辑

2.1 必选服务：已发布音频能力服务（PACS）

三、传输层基础配置：保障交互稳定的通信管道

3.1 ATT/EATT核心要求

3.2 传输层的实战意义

四、音频能力适配：强制与可选配置的精准匹配

4.1 强制支持的核心配置（必须实现，否则不兼容）

4.2 可选支持的扩展配置（按需选择，适配差异化场景）

4.3 音频能力的关键细节

五、上下文类型要求：兼容多场景的通用适配

5.1 强制支持“unspecified”上下文

5.2 上下文类型的实战价值

六、厂商自定义编解码支持：灵活扩展与标准化兼容

七、实战场景：Broadcast Sink的典型应用与配置流程

7.1 场景一：耳机接收商场背景音乐（单声道/立体声）

7.2 场景二：智能音箱接收电视多语言广播（多子组）

八、开发避坑：Broadcast Sink规范的常见误区

九、随堂测试

一、核心定位：Broadcast Sink是什么？

在深入规范前，先明确Broadcast Sink的核心使命：作为无连接广播音频的接收方，它需要发现广播源的配置信息、解码接收的音频数据、同步多设备播放节奏。典型设备包括真无线耳机、智能音箱、车载音响、运动手环等，核心价值是无连接接收+跨厂商兼容+低功耗运行。

规范对它的定义本质是被动接收但主动公示能力——不需要与广播源建立连接，但必须通过标准化服务告知外界自己的接收能力，这样广播源或Broadcast Assistant（广播辅助器）才能针对性发送适配的音频流，避免能力不匹配导致无法解码的问题。

二、核心服务部署：必选PACS服务的底层逻辑

Broadcast Sink要正常工作，必须部署唯一的核心服务——这是协议明确的强制要求，没有妥协空间，就像接收设备的能力公示牌，缺一不可。

2.1 必选服务：已发布音频能力服务（PACS）

协议强制规定：Broadcast Sink shall instantiate one Published Audio Capabilities Service。这句话的核心是，PACS是Broadcast Sink的必备基础设施，其核心作用有两个：

• 公示接收能力：通过PACS的Sink PAC特征，向Broadcast Assistant或广播源告知自己支持的编解码格式、采样率、帧长、声道数、音频位置等关键信息。比如耳机通过PACS公示“支持16kHz采样率、LC3编解码、立体声接收”，让广播源知道可以向它发送该格式的音频。

• 支撑能力协商：Broadcast Assistant扫描到广播源后，会先读取Broadcast Sink的PACS特征，判断两者能力是否匹配，再决定是否推送广播流配置，避免无效传输。

为什么PACS是必选？因为广播场景是无连接的，广播源无法主动查询接收端能力，只能依赖接收端主动公示。如果没有PACS，广播源可能发送Broadcast Sink不支持的格式，导致接收端无法解码，用户听不到声音，严重影响体验。

PACS服务的核心特征包括Sink PAC、Sink Audio Locations、Supported Audio Contexts等，这些特征共同构成了Broadcast Sink的能力说明书，是跨设备兼容的基础。

三、传输层基础配置：保障交互稳定的通信管道

Broadcast Sink的所有能力交互（如PACS能力读取、配置参数接收）都依赖ATT/EATT协议，协议对传输层的配置有明确要求，确保交互高效无差错。

3.1 ATT/EATT核心要求

• 最小ATT_MTU：64字节：协议强制要求，Broadcast Sink必须支持至少64字节的ATT_MTU，无论使用非增强型ATT承载还是增强型EATT承载。这个数值的设计逻辑和单播场景一致——广播相关的配置参数（如编解码配置、声道分配、QoS参数）通常需要30-50字节，64字节的MTU能确保这些参数一次性传输完成，避免分片导致的延迟或配置失败。

• 承载支持灵活：协议不强制要求支持EATT，但允许选择ATT或EATT。EATT基于L2CAP的增强流控模式，传输效率更高，适合大数据量交互（如多声道配置、元数据传输）；ATT则适用于简单场景，降低硬件资源占用。

3.2 传输层的实战意义

想象一个场景：Broadcast Assistant（手机）向耳机（Broadcast Sink）传输广播流配置，包含采样率、帧长、声道分配、解密密钥等参数，总长度约45字节。如果MTU是64字节，这些参数可以通过一个Read/Write指令一次性完成交互；如果MTU不足33字节，就需要分两包传输，不仅耗时增加，还可能因链路波动导致某一包丢失，最终配置失败，耳机无法接收音频。

传输层的要求看似基础，却是所有上层交互的地基——没有稳定、足够容量的传输通道，再完善的能力公示和配置逻辑也无法落地。

四、音频能力适配：强制与可选配置的精准匹配

Broadcast Sink的音频能力直接决定了它能接收哪些类型的广播音频，协议明确了强制支持和可选支持的LC3编解码配置，核心逻辑是保障基础兼容+灵活适配场景。

4.1 强制支持的核心配置（必须实现，否则不兼容）

协议要求Broadcast Sink必须支持两组LC3配置，这是跨厂商兼容的准入门槛：

• 配置1：16kHz采样率、10ms帧长、40字节/编解码帧（对应32kbps码率）。这组配置覆盖语音和基础音乐场景，是最通用的参数组合——16kHz采样率兼顾音质和带宽，10ms帧长平衡延迟和传输效率，32kbps码率在无线传输中稳定性高，所有Broadcast Source都必须支持这组配置，确保基础兼容。

• 配置2：24kHz采样率、10ms帧长、60字节/编解码帧（对应48kbps码率）。这组配置针对中高清音频场景，比如音乐播放，比16kHz音质更清晰，同时保持低延迟特性，适合对音质有一定要求的设备。

这两组强制配置的设计，本质是覆盖主流场景——既满足语音通知、公共广播等基础需求，也能适配音乐播放等中高端需求，确保不同定位的Broadcast Sink都能融入生态。

4.2 可选支持的扩展配置（按需选择，适配差异化场景）

除了强制配置，Broadcast Sink可根据产品定位选择支持其他参数组合，主要分为三类：

• 低功耗场景：8kHz采样率（搭配7.5ms/10ms帧长），码率低至24kbps，适合纯语音场景（如对讲机、机场通知），能大幅降低设备功耗，延长续航。

• 高清场景：32kHz、44.1kHz、48kHz采样率（搭配7.5ms/10ms帧长），其中44.1kHz和48kHz是音乐播放的主流采样率，码率可达80kbps以上，适合高端音箱、降噪耳机等设备，提供接近无损的音质。

• 低延迟场景：7.5ms帧长（搭配16kHz/24kHz采样率），帧长更短，传输延迟可低至微秒级，适合游戏、实时直播等对延迟敏感的场景。

4.3 音频能力的关键细节

• 码率计算规则：协议明确码率=（每帧字节数×8×1000）÷帧长（ms）。以强制配置1为例，40字节×8×1000÷10ms=32000bps（32kbps），这个计算方式确保了广播源和Sink的码率理解一致。

• 44.1kHz采样率的帧长偏差：44.1kHz+7.5ms的实际帧长为8.163ms（360样本÷44100样本/秒），44.1kHz+10ms的实际帧长为10.884ms（480样本÷44100样本/秒）。Broadcast Sink需要通过时间偏移（time_offset）补偿这一偏差，确保多设备同步播放，避免出现“同一广播流，不同耳机播放不同步”的问题。

• PAC记录格式：Sink PAC特征中的PAC记录必须包含Codec_ID、采样率、帧长、每帧字节数等关键信息。其中Codec_ID对于LC3是固定格式——第0字节为0x06（LC3编码格式值），第1-4字节为0x000000，确保广播源能快速识别。

五、上下文类型要求：兼容多场景的通用适配

上下文类型（Context Type）定义了音频的使用场景（如媒体、通话、通知），协议对Broadcast Sink的上下文支持有明确要求，核心是保障场景兼容性。

5.1 强制支持“unspecified”上下文

协议要求：

Broadcast Sink shall support the Context Type value defined as ‘unspecified’ in the Supported_Sink_Contexts field。

“unspecified”意为未指定场景，其核心作用是兼容所有未明确场景的广播音频——比如某些广播源未标注场景类型，或场景类型不在Sink支持的列表中，此时“unspecified”能作为 fallback 选项，确保音频正常接收，避免因场景不匹配直接拒绝接收。

5.2 上下文类型的实战价值

比如商场的广播源发送背景音乐（媒体场景），但某款低成本耳机只支持“unspecified”和“通知”场景，此时耳机仍能接收并播放，因为“unspecified”兼容媒体场景；如果没有这个强制要求，耳机可能直接拒绝接收，影响用户体验。

协议的这一设计，体现了兼容优先的原则——在保证核心功能的前提下，尽可能覆盖更多场景，降低设备兼容门槛。

六、厂商自定义编解码支持：灵活扩展与标准化兼容

协议允许Broadcast Sink支持厂商自定义编解码（如无损编解码、专属优化格式），但必须遵循统一的格式规范，避免出现“自定义格式无法被识别”的问题。

1. 厂商自定义编解码的Codec_ID格式

协议明确规定，自定义编解码的Codec_ID需满足：

• 第0字节：0xFF（标识为厂商自定义）；

• 第1-2字节：公司ID（来自蓝牙分配编号，如华为的公司ID为0x00E0）；

• 第3-4字节：厂商自定义编解码ID（由厂商自行定义，如0x0001代表某款无损编解码）。

这个格式的核心是标准化标识+自定义扩展——0xFF让广播源或辅助器快速识别这是自定义格式，公司ID和自定义ID确保唯一性，避免不同厂商的自定义格式冲突。

2. 自定义编解码的使用限制

厂商自定义编解码虽灵活，但有两个关键限制：

• 必须通过PACS服务的Sink PAC特征公示，让广播源或辅助器知晓；

• 不能替代强制支持的LC3配置，必须先满足16kHz和24kHz的强制配置要求，再扩展自定义格式。

这一要求避免了厂商只支持自定义格式，不兼容标准格式的情况，保障了生态的基础兼容性。

七、实战场景：Broadcast Sink的典型应用与配置流程

规范的价值最终要落地到场景，我们以两个典型场景为例，拆解Broadcast Sink的配置与工作流程：

7.1 场景一：耳机接收商场背景音乐（单声道/立体声）

设备角色：耳机=Broadcast Sink+Scan Delegator，商场音箱=Broadcast Source，手机=Broadcast Assistant；

配置流程：

7.2 场景二：智能音箱接收电视多语言广播（多子组）

设备角色：智能音箱=Broadcast Sink，电视=Broadcast Source；

配置流程：

这两个场景覆盖了公共广播和家庭娱乐的核心需求，体现了Broadcast Sink规范的灵活性和实用性——既支持低功耗的基础场景，也能适配高清、多语言的复杂场景。

八、开发避坑：Broadcast Sink规范的常见误区

基于规范要求和实际开发经验，以下几个坑点需要重点关注，避免因配置错误导致兼容问题或功能失效：

1. 忽略PACS服务的强制要求

未实例化PACS服务，或Sink PAC特征缺失关键参数（如编解码ID、采样率），会导致Broadcast Assistant无法获取接收能力，直接拒绝推送广播流配置，设备无法接收音频。开发时需确保PACS服务完整，PAC记录包含所有强制参数。

2. 音频能力不满足强制配置

只支持可选配置（如仅支持48kHz），不实现16kHz+10ms+40字节或24kHz+10ms+60字节的强制配置，会导致无法兼容大部分Broadcast Source，出现“能扫描到广播，但无法解码”的问题。

3. 传输层MTU不足

ATT_MTU设置小于64字节，导致配置参数传输分片，出现配置失败或延迟过高。开发时需确保MTU至少为64字节，复杂场景建议支持EATT提升传输效率。

4. 不支持“unspecified”上下文

仅支持特定场景（如仅支持“媒体”），不支持“unspecified”，会导致部分未标注场景的广播流被拒绝接收。开发时需确保Supported_Sink_Contexts字段中“unspecified”位为1。

5. 厂商自定义编解码格式错误

Codec_ID未遵循0xFF+公司ID+自定义ID的格式，导致广播源无法识别，自定义格式无法使用。开发时需严格按照规范格式配置Codec_ID，并在PACS中明确公示。

九、随堂测试

题目：Broadcast Sink的必选服务是什么？该服务的核心作用是什么？

答案：

必选服务是已发布音频能力服务（PACS）。

核心作用：

  ① 公示接收能力，通过Sink PAC、Sink Audio Locations等特征，向Broadcast Assistant或广播源告知支持的编解码格式、采样率、声道数等关键信息；

  ② 支撑能力协商，让广播源或辅助器判断是否匹配，避免无效传输；

  ③ 保障跨厂商兼容，为不同设备提供统一的能力交互标准。

题目：Broadcast Sink必须支持的LC3编解码配置有哪些？为什么这些配置是强制的？

答案：

必须支持两组强制配置：

  ① 16kHz采样率、10ms帧长、40字节/编解码帧（32kbps）；

  ② 24kHz采样率、10ms帧长、60字节/编解码帧（48kbps）。

强制原因：

  ① 覆盖主流场景，16kHz配置适配语音和基础音乐，24kHz配置适配中高清音乐，满足多数广播需求；

  ② 保障基础兼容，所有Broadcast Source都必须支持这两组配置，确保不同厂商的设备能无缝对接；

  ③ 平衡性能与功耗，这两组配置在音质、带宽占用、功耗之间达到最优平衡，适合无线广播场景。

题目：Broadcast Sink对传输层的核心要求是什么？该要求的设计逻辑是什么？

答案：

核心要求是支持最小64字节的ATT_MTU，无论使用ATT还是EATT承载。

设计逻辑：

  ① 满足配置参数传输需求，广播相关的配置参数（编解码配置、声道分配、QoS参数等）通常需要30-50字节，64字节的MTU能确保参数一次性传输完成；

  ② 避免分片传输问题，减少因分片导致的延迟增加、包丢失或配置失败；

  ③ 统一交互标准，为不同厂商的设备提供一致的传输层基础，保障互操作性。

问题：广播接收端为什么必须同时支持扫描委托器角色？请解释这种设计的技术原理和实际价值。

答案：

这种角色绑定设计主要基于功耗优化考虑。扫描委托器允许广播接收端将耗电的扫描任务委托给广播助手设备（如手机），接收端只需在需要时通过连接接收同步信息，大幅减少主动扫描时间。技术原理是通过PAST机制传输同步参数，实际价值是显著延长耳机、助听器等设备的电池续航。

问题：描述广播接收端通过BASS服务接收加密广播流的完整过程，包括关键步骤和交互机制。

答案：

过程分为四个阶段：首先，接收端扫描发现加密广播流，但无法直接同步；其次，通过带外方式或广播助手获取广播码；然后，使用广播码在BASS控制点触发同步请求；最后，建立同步后验证流完整性并开始解密播放。关键交互是通过BASS特性管理同步状态和广播码传递。

问题：PAST技术如何帮助广播接收端降低功耗？请说明其工作流程和节省的具体功耗来源。

答案：

PAST通过委托扫描将接收端从持续扫描中解放出来。工作流程是：广播助手主动扫描环境并发现可用广播流，当用户选择特定流时，助手通过现有连接将同步信息发送给接收端。功耗节省主要来自减少射频模块活跃时间，避免接收端自行执行耗电的周期性广告扫描过程。

博主简介

byte轻骑兵，现就职于国内知名科技企业，专注于嵌入式系统研发，深耕 Android、Linux、RTOS、通信协议、AIoT、物联网及 C/C++ 等领域。乐于技术分享与交流，欢迎关注互动！

📌 主页与联系方式

• CSDN：https://blog.csdn.net/weixin_37800531

• 知乎：https://www.zhihu.com/people/38-72-36-20-51

• 微信公众号：嵌入式硬核研究所

• 邮箱：byteqqb@163.com（技术咨询或合作请备注需求）

⚠️ 版权声明

本文为原创内容，未经授权禁止转载。商业合作或内容授权请联系邮箱并备注来意。