【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；
配置流程：
-
耳机启动后，实例化PACS服务，通过Sink PAC公示强制配置（16kHz+10ms+40字节）和可选配置（48kHz+10ms+100字节），Sink Audio Locations公示立体声（FL+FR）；
-
手机扫描到耳机和商场音箱，读取耳机的PACS特征，确认能力匹配；
-
手机获取音箱的广播配置（BASE结构、Broadcast_ID），传输给耳机；
-
耳机通过Scan Delegator接收SyncInfo和Broadcast_Codes（如需加密）；
-
耳机同步到音箱的BIG（广播同步组），解码BIS（广播同步流）中的音频数据，播放背景音乐。
7.2 场景二：智能音箱接收电视多语言广播（多子组）
设备角色：智能音箱=Broadcast Sink，电视=Broadcast Source；
配置流程：
-
音箱实例化PACS服务，公示支持24kHz+10ms+60字节（强制配置）和48kHz+10ms+120字节（可选配置），支持多语言上下文；
-
电视发送广播广告，包含BASE结构（两个子组：中文+英文，各含左右声道BIS）；
-
音箱扫描到广告，解析BASE结构，确认自己支持该编解码格式；
-
音箱同步到电视的BIG，选择中文子组的BIS，解码并播放中文音频；
-
用户切换语言时，音箱切换到英文子组的BIS，无需重新同步，快速切换。
这两个场景覆盖了公共广播和家庭娱乐的核心需求，体现了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（技术咨询或合作请备注需求）
⚠️ 版权声明
本文为原创内容，未经授权禁止转载。商业合作或内容授权请联系邮箱并备注来意。
