蓝牙用20年修一个bug：LE Audio让耳机续航翻倍

2001年，第一批蓝牙耳机上市时，没人想到这东西会塞进耳朵待8小时。当时的蓝牙音频协议（A2DP）是为"把手机放桌上、耳机挂耳朵上听个响"设计的， mono 单声道、通话为主、续航按小时算。

二十年后，真无线耳机成了标配，助听设备要全天佩戴，机场想广播通知到所有旅客的耳机里——这些场景，经典蓝牙（Classic Bluetooth）一个都扛不住。

蓝牙技术联盟（Bluetooth SIG）在2022年拍板的新标准 LE Audio，本质上是一次推倒重来。 不是打补丁，是把整个音频传输的骨架换了。新编解码器 LC3、新传输机制等时通道（isochronous channels）、新广播协议 Auracast，三件套一起上。

Android 开源项目（AOSP）从 Android 13 开始完整落地这套架构。本文从用户痛点切入，逐层拆解技术栈，最后落到代码实现。

经典蓝牙的"接力赛"困局

真无线耳机的左右耳怎么连？经典蓝牙的答案是：先连一只，再由这只"中继"给另一只。

这就导致三个顽疾。第一，主耳机功耗翻倍，永远先没电。第二，中继延迟叠加，游戏音画不同步。第三，任意一只丢包，另一只跟着卡顿，因为数据是串行的。

通话场景更尴尬。经典蓝牙用两套协议分管：A2DP 传音乐（单向、高带宽），HFP/HSP 传通话（双向、低带宽）。切换时重新协商，你听到的就是"叮"一声后音质骤降，对面说你声音像罐头。

广播功能？不存在。想给十个人的耳机同时播同一段音频，经典蓝牙得建立十个一对一连接，功耗和延迟都爆炸。

助听设备被挡在门外。经典蓝牙的功耗曲线撑不住全天佩戴，也没有标准化的低延迟音频流规范，各厂商各自为战。

LC3 编解码器：用一半带宽，听更好声音

LE Audio 的核心武器是 LC3（Low Complexity Communication Codec），由 Fraunhofer IIS 和 Ericsson 联合开发。

它的设计目标很直接：在经典蓝牙主力编解码器 SBC 一半的比特率下，达到同等或更好的音质。

SBC 是 2003 年的技术，子带编码，固定分帧，复杂度低但效率也低。LC3 改用基于修改离散余弦变换（MDCT）的时频分析，支持动态帧长（7.5ms 或 10ms），能根据内容自适应分配比特。

实测数据：LC3 在 160 kbps 的音质，SBC 需要 328 kbps 才能接近。 这意味着同样电池容量，LE Audio 设备可以多播一倍时间。或者反过来，同样续航目标，电池可以砍半，耳机轻 3 克。

更隐蔽的好处是抗丢包。LC3 内置丢包隐藏（PLC）算法，单帧丢失时通过频谱预测填补，用户几乎无感知。SBC 丢一帧就是"咔"一声。

LC3 还分两个档次：LC3 标准版面向 64-192 kbps，LC3plus 扩展到 500+ kbps 并加入无损模式。后者瞄准专业音频，但 LE Audio 规范目前只强制要求标准版。

等时通道：给音频流修一条专用高铁

经典蓝牙用两种"管道"传数据：ACL（异步连接导向，文件传输、控制命令）和 SCO（同步连接导向，通话音频）。

SCO 的问题是老式固定时隙，2.4GHz 干扰一多就抖动，且不支持现代蓝牙的低功耗（LE）物理层。

LE Audio 引入等时通道（isochronous channels），直接架在 LE 物理层上，分两种形态：

• 单播等时流（CIS，Connected Isochronous Stream）：一对一，带确认重传，适合通话、游戏

• 广播等时流（BIS，Broadcast Isochronous Stream）：一对多，无确认纯广播，适合公共音频、电视伴音

关键设计是时间同步。发送端按固定间隔（ISO interval）打包，接收端提前知道每个包该几点到，准时醒来、收完即睡。这种"预约制"比经典蓝牙的"随时可能来数据"省电得多。

CIS 支持双向，左右耳可以各建一条独立 CIS 到手机，彻底告别中继。BIS 支持无限接收端，机场装一个发射器，理论上几千副耳机都能同步收听到登机通知，延迟控制在 20ms 以内。

等时通道还带了新角色：同步组（CIG/BIG）。同一组内的多个流共享时钟基准，确保左右耳听到的采样点严格对齐，消除立体声相位差。

协议栈重构：从七层蛋糕到模块化积木

LE Audio 不是单一规范，是一摞协议的协同。蓝牙 SIG 把它组织成四层：

最底层是 BAP（Basic Audio Profile），定义音频角色（源/汇/广播源/广播汇）、流建立流程、编解码器能力协商。所有 LE Audio 设备必须实现 BAP。

往上是 PACS（Published Audio Capabilities Service），每个设备广播自己支持什么：采样率、声道数、LC3 比特率范围、是否支持辅听功能。连接前就能互相"看简历"，减少协商轮次。

再往上是按场景切分的应用协议。CAP（Common Audio Profile）统筹多设备协同，比如手机同时给耳机和助听设备推流。TMAP（Telephony and Media Audio Profile）管通话和音乐，替代旧的 HFP/A2DP。HAP（Hearing Access Profile）专门规范助听场景，包括环境音增强、远程麦克风、音量标准化。

最顶层是 Auracast 品牌协议，定义广播音频的公共体验：用户怎么发现附近有哪些广播、怎么切换、怎么保证隐私（广播可以加密，但公共场景通常开放）。

这套架构的野心是统一。 一副耳机，既能连手机听歌，又能收机场广播，还能当助听器的远程麦克风——三种场景，同一套底层协议，自动切换。

AOSP 实现：从 Java API 到固件寄存器

Android 13 起，LE Audio 完整进入 AOSP。路径很长，我们分层走。

应用层看到的是 AudioManager 和 BluetoothLeAudio 的新 API。开发者调用 setActiveDevice() 切换输出，系统内部会走 AudioPolicy 服务，把音频流路由到正确的 HAL（硬件抽象层）。

Framework 层，BluetoothLeAudio 服务管理连接状态机。发现设备时读取 PACS 广播，建立 CIS 时协商 LC3 参数（采样率、帧长、比特率）。多设备场景下，CAP 协议协调多个音频汇的同步播放。

Native 层是重头戏。libbluetooth.so 里的 le_audio 模块实现了完整的 LE Audio 协议栈：BAP 的状态机、ISO 数据包的组装拆解、LC3 编码器的调用（通过 Android 的 Codec2 框架）。代码路径在 system/bt/stack/le_audio/。

LC3 编解码器本身以预编译库形式提供，vendor 分区可替换。Google 在 AOSP 里放的是参考实现，实际设备商（如高通、联发科）会用自己的优化版本。

最下层是 HAL 和固件。Android 的蓝牙 HAL 3.0 新增 LE Audio 专用接口：IsochronousChannel、LeAudioCodecConfiguration、BroadcastCreate。芯片厂商（如 Nordic、Silicon Labs、高通）的固件负责把 HCI 命令转成射频波形，处理跳频、重传、功耗管理。

一个细节：AOSP 里的广播实现（Auracast 接收端）目前需要设备支持同步接收多个 BIS 子流，这对控制器算力有要求。低端芯片可能只实现单播，广播功能被软屏蔽。

用户能感知的变化

LE Audio 落地后，几个老痛点会消失。

左右耳电量差。独立 CIS 连接让两只耳机平摊功耗，实测续航差异从 30% 降到 5% 以内。

通话音质断崖。TMAP 统一了媒体流和通话流的编码，LC3 全程在线，不再切到 CVSD（经典蓝牙通话用的 8kHz 老古董）。

分享音频。Auracast 广播让"一起听歌"不需要碰手机，机场、健身房、博物馆可以部署公共音频点，用户像连 Wi-Fi 一样选择加入。

助听设备无缝化。HAP 规范让消费级耳机和医疗级助听器用同一套协议对话，iPhone 先走一步，Android 14 起追平。

但迁移有成本。LE Audio 和经典蓝牙音频不兼容，需要手机、耳机、甚至发射端三方都支持。蓝牙 SIG 的预测是 2024-2025 年主流设备完成切换，目前（2025 年初）中高端 Android 手机和新款 TWS 耳机已普遍支持，老设备只能 Classic 模式 fallback。

一个值得玩味的细节：AOSP 代码里，LE Audio 的广播发射功能（当广播源）目前只开放给系统应用，第三方 App 还调不了。Google 的解释是功耗和频谱管理需要平台管控，但开发者社区有异议——如果我想做个"本地导游讲解"App，让用户手机当发射器，现在还不行。

这个限制会松动吗？还是 Google 在等某个硬件生态成熟？