Auracast广播音频开发实践：基于BT2106C的一对多音频同传方案

上个月，我第一次把一套 Auracast 广播音频模块真机跑通。调试间里，两台手机、一副 TWS 耳机，外加协议栈日志窗口，几乎同时开始输出同一段音频波形——这几个设备之间没有做任何配对，也没有建立任何连接，这在传统蓝牙音频链路里几乎不可能做到。音频来源是一块 BT2106C 蓝牙广播模块，外部 codec 把模拟声音变成 I2S 数据送进模块，模块内部完成 LC3 编码后，以广播等时组（BIG）的方式发出去。

这篇把这次开发的选型过程、工程落地、效果实测和踩坑记录完整写下来。为什么 Auracast 适合一对多的音频分发、BT2106C 怎么快速跑起来、空中接口参数怎么设，以及最终同步性、延迟和穿墙能力的实测结果，都在后面。还有几个不用真机根本看不出来的坑，尤其是那些排查链路，建议做同类项目的朋友认真看。

1. 从“一拖二”到无上限同听：为什么最终选了 Auracast 路线

1.1 现场讲解和同传场景的真实痛点

项目背景是做一套现场语音导览设备。一个讲解员、一堆游客，游客用自己的手机或耳机收听同一路声音源。最初方案用的经典蓝牙音频发射器，一个发射器最多稳定连一到副接收端，而且很多耳机根本不支持同时连接，常常一台设备刚连上，另一台就被挤掉了。也试过 Wi-Fi 方案，接收端要先配网、再打开 App 选择播放地址，游客操作门槛太高，现场基本跑不起来。

Auracast 在这类场景里几乎是量身定做的。它走的是 BLE 广播通道，发射端的音频数据通过周期性广播发出去，任何支持 LE Audio 的接收端只要处于可发现状态，就能直接收听。不需要配对、不需要输入密码、不需要连接路由器，跟打开收音机听一个频段一样简单。这个特性对博物馆导览、会议室同传、影院辅助听力这类场景特别关键，因为使用者大概率不是技术人员，越少操作的方案越好。

1.2 与经典蓝牙转发方案的差异

把几种方案放一起对比就非常直观：

我一开始对 Auracast 也有疑问：广播通道这么忙，音频能被多个接收端稳定收到吗？实际测试下来，广播音频在接收端数量上确实有天然优势，因为接收端只是被动监听，不占用发射端的连接资源，发射端完全不需要为接收端数量的增加付出额外的空中带宽。对比之下，CIS 单播方案每增加一路收听设备，发射端就要多维护一条逻辑链路，连接数一旦上去，调度复杂度就会指数级上升。

1.3 BT2106C 的选型理由

选 BT2106C 之前，我评估过三类方案。第一类是用一颗高性能 MCU 外挂蓝牙射频芯片，音频编码和协议栈全自己写，灵活但开发量太大；第二类是用手机做发射端，配合 BLE Audio 广播 API，功能够用但没法脱离手机，不适合做成独立硬件；第三类就是 BT2106C 这类集成了蓝牙协议栈和 LC3 编码的专用模块。最后选了第三类，理由很直接：模块内部已经跑好了 BIG 广播协议栈和 LC3 编码器，我只需要通过 I2S/PCM 接口把音频数据喂给它，等于把最复杂的部分黑盒化，节省了大量开发时间。

另外几个硬件细节也值得提。模块的 PCB 天线是板载的，体积小，方便直接贴到产品主板上；音频输入支持 I2S 和 PCM 两种模式，兼容常见的音频 codec；功耗在可接受范围，后续做电池供电产品还有优化空间。还有就是厂商 SDK 里带了一个 Auracast 发射端的参考例程，虽然不是拿来就能量产，但至少把 BIG 配置、广播启动、协议栈回调这些骨架都搭好了，对照着改比从零开始容易得多。

2. 先理解 Auracast 的广播模型：BIG、BIS、事件间隔和重传预算

2.1 一列火车理解 BIG 与 BIS

Auracast 的底层机制是 BIS（Broadcast Isochronous Stream）和 BIG（Broadcast Isochronous Group）。用一列火车来类比会直观很多：BIG 就是整列火车，负责把一路或多路音频数据从一个发射端送到任意多个接收端；BIS 是其中的一节车厢，对应一路独立的音频流。一个 BIG 里可以挂多个 BIS，比如同一场发布会，BIS 0 放现场原声，BIS 1 放中文同传，BIS 2 放英文同传，接收端根据自己的需要选择听哪一节车厢。

火车每次停靠站台，就是一个广播事件。事件到站的时刻是事先约定好的，接收端不需要和发射端连接，只要在正确的时间点打开射频窗口等这列火车经过，取走属于自己的车厢数据即可。这个周期性到达的音频数据包，在协议里叫 SDU，里面装的就是经过 LC3 编码后的音频帧。接收端收集到足够的 SDU 后，按时间顺序解码播放，就形成了连续的声音。

2.2 BIG 参数直接影响延迟和覆盖能力

刚开始调参数时，我对 BIG 周期、SDU 大小、事件间隔这些概念之间的关系很模糊。实际调过之后才明白，它们其实是同一件事的不同侧面。LC3 编码器通常以 10ms 为一个音频帧，所以发射端一般也把 BIG 周期的 SDU 间隔设成 10ms，这样一个 SDU 就装一帧 LC3 数据。

一个很实用的计算公式是：SDU 大小 = 比特率 × 音频帧时长 / 8。比如 32kbps 比特率、10ms 音频帧，每个 SDU 就是 40 字节。如果选择 64kbps 高音质，SDU 就会变成 80 字节。SDU 越大，单个事件里需要发送的空中数据越多，射频占用时间越长，功耗也越高，但音质更好。下面是几组我实测过的参数配置：

有一点必须提醒：SDU 间隔和 BIG 周期不是可以随便设的。如果 SDU 间隔是 10ms，BIG 周期最好也是 10ms 的整数倍。强行把 BG 事件间隔设得比 SDU 长，接收端就会因为拿不到完整数据而频繁重同步，声音断断续续。这种问题在日志里不一定有明显报错，排查起来非常费劲。

2.3 重传是 Auracast 覆盖的隐藏旋钮

普通 BLE 广播包发一次就结束，丢了就丢了。但 BIS 广播不一样，一个 BIG 事件内部可以由多个子事件组成，同一个 SDU 可以在不同子事件里重复发送，接收端只要在任意一个子事件里成功收到完整数据，就算这一帧没丢。

这个机制对覆盖能力的帮助远大于单纯加大发射功率。我实测过一个场景：发射功率从 0dBm 加到 +6dBm，隔一堵墙的丢包率只下降了几个百分点；但把重传次数从 1 调到 3，同样环境下丢包率直接降了一个数量级。原因也很简单，室内的多径衰落和突发干扰是随机的，同一包数据在稍后几十微秒再发一次，大概率能绕开前一次遇到的干扰窗口。所以调覆盖时，先看重传配置，再决定要不要动功率。

3. 工程搭建与 SDK 准备：最容易拖慢开发节奏的几个环节

3.1 先锁定 SDK 版本，别直接追最新

BT2106C 这类模块的 SD K，大多把 Auracast 功能放在特定的发布分支里。我第一次拿到模组时，习惯性地拉了厂商 SDK 的最新代码来编译，结果一连串接口对不上，编译报错几十行。后来才发现，最新代码里 Auracast 相关组件正在重构，接口和稳定分支完全不一样。

正确做法是先找到模块厂商提供的 Auracast demo 工程，确认它在哪个 SDK 版本下能正常编译通过，然后把整个 SDK 锁定到那个版本。后续不要随便升级大版本，除非有明确的功能修复需求。开发过程中如果看到文档里说“需要更新协议栈”，也要谨慎评估，协议栈升级往往会导致广播参数或回调接口变化，牵一发动全身。

3.2 跑通 demo 前的硬件细节确认

软件之前，先把硬件接对。我踩过电源纹波的问题，模块发射瞬间的峰值电流会让电压跌落，导致射频输出功率不稳定，接收端就会出现随机卡顿。建议给模块单独加一颗低 ESR 的 10uF 陶瓷电容，靠近供电引脚放置。

天线区域同样不能马虎。BT2106C 板载天线周围要禁空，不能铺铜，不能走信号线，否则天线失谐后辐射效率直线下降。我第一次测试时天线旁边贴了一颗电源芯片，空旷距离直接缩短了三分之一，重新改板后才恢复正常。I2S 信号线也尽量短，串行时钟和数据线如果走太长，高速翻转时容易产生振铃，影响音频采样的稳定性。

3.3 用 demo 验证接收端兼容性

把 demo 工程编译烧录进去之后，别急着改代码，先做一次完整的接收端兼容性测试。用手机系统自带的音频广播功能扫描，再用支持 LE Audio 的 TWS 耳机试听。接收端能搜到广播、能正常出声，说明 SDK 的 Auracast 实现本身是符合规范的，后面出了问题可以放心排查自己的业务逻辑。

如果这一步就失败了，优先怀疑硬件问题，比如天线、电源、时钟精度，而不是急着调协议栈参数。demo 是厂商验证过的，在 demo 跑不通的情况下改业务代码，会把 SDK bug 和自己的 bug 混在一起，排查成本非常高。

4. 代码落地：广播组创建、LC3 音频注入与小状态机设计

4.1 广播组参数怎么配置

跑通 demo 之后，第一件正事就是按自己的音频链路配置 BIG。核心参数是 SDU 间隔、SDU 大小、BIS 数量和重传次数。参考代码片段如下，接口名以实际 SDK 为准：

/* 简化示意，具体API按厂商SDK调整 */ #define AUDIO_SAMPLE_RATE 32000 #define LC3_BITRATE 32000 #define ISO_INTERVAL_MS 10 static const ble_audio_broadcast_cfg_t bt_cfg = { .broadcast_name = "Tour_Audio", .big_period_ms = ISO_INTERVAL_MS, /* 一个BIG周期 */ .num_bis = 1, /* 单声道，一路BIS */ .bis[0] = { .sdu_interval_us = 10000, /* 每10ms一个SDU */ .max_sdu_bytes = LC3_BITRATE * ISO_INTERVAL_MS / 8, /* 40 */ .phy = ERA_PHY_1M, .retransmissions = 2, /* 子事件重传次数 */ }, };

max_sdu_bytes的计算逻辑就是前面提到的公式：32000 × 0.01 / 8 = 40 字节。如果音频源变化，或者想提高音质，只需要调整LC3_BITRATE和ISO_INTERVAL_MS，SDU 大小会自动跟着变，不用手动硬编码。

4.2 启动流程与状态回调

BIG 广播的启动不是一个同步动作，而是一个异步流程。调用启动接口后，协议栈需要时间完成广播参数的准备和空中链路的建立，结果通过回调函数通知应用层。所以代码里必须有一个清晰的状态机，至少包含初始化、启动中、运行中、停止中四个状态。

static void device_event_handler(device_event_t event) { switch (event.type) { case BIG_STARTED: /* 协议栈已经完成BIG广播的建立，可以开始写音频数据 */ audio_thread_start(); break; case BIG_STOPPED: audio_thread_stop(); break; default: break; } }

很多初稿代码会在调用完启动接口后立即开始写入音频数据，结果前几个 SDU 被协议栈丢掉了，接收端播放时开头就缺一段。正确做法是等BIG_STARTED回调通知后再启动数据写入线程，宁可晚几十毫秒开始，也不能丢数据。

4.3 音频注入任务的设计

音频注入是整个系统里最容易出问题的部分。我的实现方式是用一个独立任务负责从环形缓冲区读取 I2S DMA 送进来的 PCM 数据，每满 10ms 就做一次 LC3 编码，然后把编码后的 SDU 写入协议栈提供的广播发送接口。

void audio_processing_task(void* arg) { uint8_t pcm_buf[320 * 2]; /* 32kHz采样率，10ms，16bit，单声道 */ uint8_t enc_buf[40]; /* LC3 32kbps，10ms帧的编码输出 */ while (running) { if (ringbuffer_read(pcm_buf, sizeof(pcm_buf)) != 0) { continue; } lc3_encode(pcm_buf, enc_buf); ble_audio_broadcast_write(big_handle, 0, enc_buf, sizeof(enc_buf)); } }

这个任务的关键是时序稳定。如果任务被更低优先级的业务代码卡住，SDU 写入就会出现缺口，接收端检测到序列号跳变后要重新同步，表现就是声音卡顿。优先级设置上，建议音频任务优先级低于协议栈任务、高于普通业务任务，给协议栈留出足够的调度空间。

4.4 从 demo 到产品的状态机差异

厂商 demo 例程通常只是循环播放一段内置音频，完全没有处理真实的业务场景。切换到实际产品时，我加了三类逻辑。第一是音频源健康检查，外部 codec 没初始化好或者 I2S 信号丢失时，不能直接把垃圾数据送进编码器。第二是静音帧填充，即使当前没有有效音频，也要持续发送编码后的静音帧，保持 SDU 序列号连续，接收端才不会因为长时间没收到数据而退出播放状态。

第三是异常恢复。中途如果 BIG 广播意外终止，比如协议栈复位或者射频异常，必须能自动重新走一遍启动流程，而不是停在错误状态。这个在开发测试阶段不一定触发，但到了现场就会变成致命问题。我在整个状态机里加了一个看门狗式的定时检查，超过 3 秒没有收到协议栈事件就主动重新初始化广播链路。

5. 真机实测：同步性、延迟和穿墙数据

5.1 测试环境与接收端设备

测试分两轮进行。一轮在办公楼室内，测试穿墙能力和多设备共存；另一轮在户外开阔广场，测试极限距离。发射端用 BT2106C 模块，天线是板载 PCB 天线，发射功率分别测了 0dBm 和 +6dBm 两组。接收端用了一台 Android 15 手机、一台支持 LE Audio 的 TWS 耳机，以及一个厂商提供的测试接收棒。

测试方法很简单：发射端固定，接收端拿着逐步远离，在固定距离点停留 30 秒，观察音频是否连续、是否出现爆音或卡顿。同时用协议栈日志抓取每个距离点的 RSSI 和丢包率，作为后续调优的参考。

5.2 距离与穿墙实测结果

从这个结果可以清楚看到，加功率的效果远不如加重传。0dBm + 重传 1 次在隔两堵墙时已经基本不可用，但同样的发射功率下，把重传次数提高到 2，仍然能维持可用状态。实际产品我最后选择的是 +6dBm、重传 2 次的组合，覆盖和功耗相对平衡。

5.3 延迟和多设备同步表现

延迟实测结果在意料之中。从音频信号进入发射端 I2S 输入，到 TWS 耳机真实发声，整体延迟大约在 180~230ms 之间。这个延迟包含了 LC3 编码、BIG 广播、接收端缓冲、解码播放几个环节，对于导览和同传场景完全可接受，人耳感知不到明显的不同步。

多设备同步性是我最关心的一个指标。用两台 Android 手机同时接收同一路广播，人耳听不出先后差别，用录音设备抓波形看，两台手机之间大约相差 30~80ms。原因是每台手机接收端的缓冲策略不同，有的为了抗丢包会把缓冲区开大一点。广播源只有一个，所以只要接收端本地时钟同步机制正常，就不会出现一台机器声音落后另一台太多的离谱情况。

5.4 参数调优前后的数据对比

我专门做了一组对照测试，验证重传次数对无线性能的影响。测试场景是室内隔一堵轻墙，固定发射功率 +6dBm，接收棒放在约 12 米处，每轮测试播放 3 分钟，统计丢包率：

可以看到，信号强度几乎没变，但丢包率从 18.6% 降到了 0.5%。这就是子事件重传机制的价值。重传 3 次相比重传 2 次的提升已经不明显，但功耗有一定增加，所以最终量产配置选了重传 2 次。

6. 踩坑链路复盘：从“接收端搜不到”到十五分钟后的时钟漂移

6.1 坑一：接收端彻底搜不到广播

这个坑出现在业务工程改造完成后。厂商 demo 在测试机上可以被搜到，但我把代码迁移到自己的工程后，手机端显示找不到任何 Auracast 广播源。第一反应是配置项丢了，但逐个对比后广播参数完全一致，这就很诡异。

排查链路如下：先用 BLE 抓包工具在空中抓广播包，发现模块确实在周期性地发送广播数据，说明物理层没问题；进一步解析广播包内容，发现广播地址类型被设置成了随机私有地址，而系统级 Auracast 接收端只会列出使用公开广播地址或固定广播地址的音频广播源。最终的修复方式是修改广播地址类型配置，并确保广播元数据里填充了正确的广播名称和可用的 BIS 列表。手机端才能正常识别。

这个坑的教训是：Auracast 广播能不能被系统级接收端发现，不只取决于射频和 BIG 参数，还取决于广播元数据是否符合规范，尤其是广播地址类型和广播名称字段。单独用自定义接收端调试没问题，但换到标准手机就失灵，首先查这两项。

6.2 坑二：隔墙后声音断断续续

第一次现场测试时，空旷区域一切正常，但人一走到柱子后面或隔墙位置，声音就开始打磕巴。当时我第一反应是发射功率不够，于是把功率从 0dBm 一路加到 +6dBm，结果改善非常有限。

随后用日志定位 RSSI 数据，发现隔墙场景下信号强度并没有特别差，平均在 -75dBm 左右，但丢包率却高达两位数。这说明问题不在链路预算，而在多径衰落和突发干扰。多径衰落的特点是信号强度看似还行，但某些子载波/时隙上会出现深度衰落，单次发送大概率丢失。解决思路转向提高重传次数，实测重传从 1 调到 2 后，丢包率明显下降。

现在遇到这类问题，我的排查顺序是：先看 RSSI，如果信号强度高于 -80dBm 但仍然卡顿，优先调重传次数；如果 RSSI 很低，再考虑加功率和天线优化。盲目加功率既增加功耗，又在强干扰环境里帮助不大。

6.3 坑三：播放约十五分钟后延迟明显漂移

这个坑最隐蔽。测试刚开始时一切正常，但连续播放到十五分钟左右，手机上看到的声音开始明显比现场声源的节奏慢，而且这个偏差还在缓慢增大。这不是固定延迟，而是一种持续漂移。

排查链路先排除了发射端问题，因为我同时用接收棒监听，接收棒输出和现场声源同步正常。问题锁定在手机接收端。进一步分析是接收端的本地时钟和发射端时钟之间产生了累积偏差。BLE 广播音频虽然带有周期性同步机制，但接收端如果长时间没有进行时钟校准，或者校准任务被系统调度延迟，累积的偏差就会反映成声音速度变慢。

解决方式分两步。第一步，把发射端的事件间隔和时钟精度相关配置调准，确保发射端的广播时间轴尽可能稳定。第二步，检查接收端协议栈线程优先级，保证时钟校准任务不被低优先级任务阻塞。调完后再做一小时连续播放测试，漂移控制在 20ms 以内，基本感知不到。

6.4 坑四：I2S 主时钟精度导致音调轻微异常

有段时间播放声音总觉得音调稍微偏高或偏低，听感上很像磁带转速不对。使用音频分析仪抓输出波形才发现问题不在无线链路，而在音频源本身：I2S 总线的采样率标称 32kHz，实际却因为主时钟精度不够，导致数据速率与理论值有偏差。

LC3 编码器对输入采样率非常敏感。如果实际采样率低于标称值，单位时间内产生的 PCM 数据不足，发射端为了保证 SDU 序列号连续，会在编码前补帧，补出来的帧会让接收端解码后的时长变长，听起来就是声音拖慢。反之，采样率偏高则声音偏快。最终解决方法是给 codec 使用独立的外部 MCLK 时钟源，精确锁在 32kHz 的整数倍频率上，然后由 codec 将主时钟分频产生 I2S 的位时钟和帧时钟，彻底解决了漂移和音调问题。

6.5 坑五：调试串口日志与广播并发导致卡顿

这个坑属于低级问题，但很容易被忽略。开发阶段为了方便，我把协议栈调试日志的串口波特率设得非常高，而且日志等级开到了详细级别。结果在音频广播的同时，串口持续输出大量日志，占用了 CPU 和中断时间，音频任务偶发得不到及时调度，声音就开始一卡一卡。

排查时一度以为是射频干扰，后来发现拔掉调试串口线就正常。最终处理方式是把调试日志等级调到警告以上，并降低串口打印频率。量产固件里调试日志必须关掉或只保留错误级别的输出，这个建议看起来基本，但确实能省掉很多现场的无线调试时间。

7. 如果再来一次，我会先用一整天专门测天线和时钟

整套项目做完，回头看最大的经验就是：Auracast 开发里最耗时的不是写代码，而是确认硬件基础和参数配置。协议栈接口再复杂也有文档可查，但天线匹配、电源纹波、I2S 主时钟精度这些问题，不实测根本发现不了，而且发现得越晚，改造成本越高。

如果重新做一次选型和开发，我会把验证顺序调整到：先测模块在各种环境下的覆盖和丢包，确认天线和电源没问题；再测 I2S 音频链路的采样率精度，确保 LC3 编码器输入是准的；最后才开始写业务代码。按这个顺序走，后面调协议栈参数时就不用怀疑底层硬件，排查周期能缩短一半以上。

这套基于 BT2106C 的 Auracast 广播音频方案最终交付时，接收端包括手机、TWS 耳机和专用接收棒，都能在同一时间稳定收到现场音频。对我个人来说，最有成就感的瞬间反而不是跑通的那一下，而是把十五分钟后时钟漂移问题定位到协议栈线程优先级的那一刻。这种坑，文档不会写出来，只有真机长时间测试才能遇到。