006 低功耗蓝牙BLE——音频数据无法直接免驱传输分析与折中方案

蓝牙设备的音频传输方式主要依赖于其采用的分层​​传输协议​​和​​音频编解码器​​，两者共同决定了音质、延迟、功耗等核心体验。

本次产品核心需求——免驱！

---

---

00 市面上的USB免驱麦克风方案分析

USB麦克风的免驱特性依赖​​操作系统内置的UAC（USB Audio Class）驱动​​，而非HID协议。核心原理如下：

设备枚举与协议支持​​
USB插入时，设备通过描述符（设备描述符bDeviceClass=0x00，接口描述符bInterfaceClass=0x01）声明为音频类设备。操作系统自动加载UAC驱动（Windows的usbaudio.sys，Linux的snd-usb-audio）

• ​​关键描述符​​：音频类设备需提供完整的接口描述符（包含采样率、位深等参数），端点描述符定义同步传输模式（Isochronous Endpoint

与HID的本质区别​​
HID设备（如键盘）的接口描述符为bInterfaceClass=0x03，使用中断传输传输小数据包（如按键事件）。而音频设备需高速传输原始PCM流，必须采用同步传输（带宽高、无重传机制）

• ​​HID局限​​：报告描述符（Report Descriptor）无法定义音频流格式，且传输速率不足（BLE HID单包仅20字节）

免驱实现核心​​

• ​​无需厂商驱动​​：操作系统通过UAC协议直接解析音频流格式（如16bit/16kHz PCM），无需定制驱动
• ​​例外情况​​：若麦克风集成高级功能（如AI降噪），需额外安装控制软件（但基础录音仍免驱）

维度​​	​​UAC音频方案​​	​​HID控制方案​​
​​协议类型​​	USB Audio Class (UAC 1.0/2.0)	HID Class (bInterfaceClass=0x03)
​​传输端点​​	同步传输端点（Isochronous）	中断传输端点（Interrupt）
​​数据内容​​	原始PCM音频流	控制指令（如静音、增益调节）
​​带宽能力​​	支持高带宽（24bit/192kHz）	低速（≤64KB/s），仅适合小数据包
​​免驱原理​​	操作系统内置UAC驱动	操作系统内置HID驱动
​​典型应用​​	麦克风音频采集、耳机播放	键盘按键、鼠标移动、设备控制指令

USB是协议总框架​​，HID与UAC是USB协议中定义的​​两种独立的设备类别

01 蓝牙音频传输方案分析

USB麦克风是一个符合我们产品设计要求的方案，但理想很美好——蓝牙无法直接采用UAC方案​​

UAC是USB-IF为​​有线USB设备​​定义的音频传输标准，依赖操作系统内置的UAC驱动（如Windows的usbaudio.sys）
而蓝牙采用​​无线射频协议栈​​（如A2DP/HFP），由蓝牙芯片组和主机协议栈（如Android的Bluetooth Stack）管理音频通道，两者底层架构完全不同。再者​​蓝牙​​物理层带宽有限

下面分析实际音频信息的传输中，遇到一些BLE音频传输方案：
HID、 ATVV（Android TV Voice）、tspp这三种协议在整个音频传输生态中的定位和相互关系

​​HID协议传输​​

• ​​定位​​：专为人机交互设备（键盘、鼠标、触摸屏、游戏手柄等）设计，通过USB或蓝牙传输低延迟控制信号，音频仅用于语音输入（如麦克风）。
• ​​传输机制​​：
  • USB HID：通过​​中断传输​​（Interrupt Transfer）实时发送报告（如按键状态）
  • 蓝牙HID：通过BLE的​​GATT协议​​传输报告，数据量小（通常<64字节）
• ​​音频应用​​：仅支持​​单声道语音​​（如通话麦克风），音质较低（8kHz/8bit）

带宽不够，实际使用时需要压缩，不免驱

TSPP传输（MPEG2-TS）​​

• ​​定位​​：音视频​​流媒体传输协议​​，用于数字电视广播（DVB/ATSC）、蓝光光盘（M2TS）等场景，支持多节目复用和高容错。
• ​​传输机制​​：
  • 数据封装为​​188字节固定长度分组​​，头部含PID标识流类型（视频/音频/数据）
  • 通过​​PSI表（PAT/PMT）​​ 管理多路流同步（如音频PID关联视频PID）
• ​​音频应用​​：承载压缩音频流（如AC-3、DTS），支持​​多声道、高码率音频​​（如蓝光无损音轨）

不免驱

ATVV服务（实际是BLE GATT​）：

 ​​ATVV（Android TV Voice）协议是基于蓝牙低功耗（BLE）的 GATT（Generic Attribute Profile）协议​​

• ​​传输机制​​：
  • ​​音频数据​​：使用 ​​ADPCM（自适应差分脉冲编码），通过 Audio 特征值的 ​​Notification​​ 机制发送（无确认，高速传输）
  • 控制命令​​（如开始/停止录音）：通过 Command 特征值的 ​​Write​​ 操作传输​
• ​​定位​​：​Android TV 语音专有协议​ 
• 应用：电视语音遥控

免驱实现：蓝牙芯片可能需要支持蓝牙核心规范版本5.3或更高版本，以确保兼容BAP配置文件

方案​​	免驱支持	音频质量	延迟	开发复杂度
​​GATT+LE Audio​​	✅ Android 13+/Win11+	近无损（LC3）	20-50ms	高
​​GATT自定义​​	❌ 需专属App	可自定义	30-80ms	中

 

经典蓝牙（BR/EDR）方案​

​​协议选择​​：

• ​​A2DP（高级音频分发协议）​​：支持立体声PCM传输，但强制使用编码器（如SBC/AAC/aptX）压缩数据
• ​​HFP/HSP​​：仅支持单声道、低采样率（8kHz/8bit），音质差，适用于通话场景

局限​​：

• A2DP延迟较高（100-200ms），且无法绕过编码环节传输原始PCM

维度​​	​​A2DP协议​​	​​HFP/HSP协议​​
​​核心功能​​	​​单向传输高质量音频流​​（如音乐播放）	​​双向音频传输​​（支持麦克风输入+扬声器输出）
​​音频类型​​	立体声音乐（最高48kHz/16bit）	单声道语音（通常8kHz/8bit，HFP可扩展至16kHz）
​​传输方向​​	仅支持源设备→接收设备（如手机→耳机）	支持双向传输（手机↔耳机，麦克风→PC）
​​免驱支持​​	系统识别为“音频播放设备”	系统识别为“通话设备”或“麦克风+扬声器”
​​典型应用​​	音乐耳机、蓝牙音箱	通话耳机、车载免提、会议麦克风

LE Audio方案（蓝牙5.2+）​

革新点​​：
引入​​LC3编码器​​，支持低码率（32kbps）高音质，延迟≤20ms

​​原生支持PCM流程​​：
通过​​HAP（Hearing Access Profile）​​ 或​​BAP（Basic Audio Profile）​​ 直接传输PCM数据流，但需设备端和主机操作系统支持（如Android 13+）

LE Audio（BAP）方案在Android和Windows平台的实际部署进度与厂商支持情况的综合分析：

Android平台支持现状

系统层支持​

• Android 13​​：首次提供LE Audio框架支持，但需设备制造商激活（默认关闭开发者选项）
• ​​Android 15​​：原生深度集成BAP协议栈，系统级启用LE Audio（无需开发者模式）

Windows平台支持现状​

系统层支持​

• ​​Windows 11 22H2+​​：首个支持LE Audio的桌面系统，需版本≥22621
• ​​Windows 10​​：​​不支持​​，因缺乏TMAP（Telephony and Media Audio Profile）

协议​​	​​数据类型​​	​​传输方向​​	​​带宽要求​​
HID	控制信号(按键事件)	单向(设备→主机)	低(＜1Kbps)
ATVV	音频流 + 控制命令	​​双向​​	中(16-32Kbps)
TSPP	音视频TS流	单向(广播→设备)	高(＞2Mbps)

​指标​​	HID	ATVV	TSPP
​​延迟​​	＜10ms	20-50ms	100-500ms
​​功耗​​	极低(纽扣电池)	低(BLE优化)	高(需外部供电)
​​音质​​	不支持音频	16KHz ADPCM	48KHz AAC
​​拓扑结构​​	点对点	点对点	一对多广播
​​典型应用​​	遥控器按键	语音遥控器	数字机顶盒

02 基于HFP/HSP的无线麦克风免驱输入方案分析

设备角色配置​

HFP（免提规格）​​：

设备声明为​​免提单元（Hands-Free Unit）​​，支持：

• 麦克风音频输入（传输至手机/PC）
• 扬声器音频输出（接收来自手机/PC的音频）
• 通话控制（接听/挂断/拒接）

HSP（耳机规格）​​：

简化版HFP，仅支持基础麦克风传输，无扩展控制功能

免驱原理：

操作系统内置协议栈​​：

• ​​Windows​​：自动加载bthhfenum.sys（HFP驱动）和usbaudio.sys（音频驱动）
• ​​Android/iOS​​：原生支持HFP，识别为“蓝牙耳机”或“输入设备”

连接流程​​：
设备广播HFP支持 → 手机/PC自动配对 → 注册为系统​​默认麦克风设备​

很遗憾，我们的芯片方案早已确定——HS6621CQC是BLE蓝牙协议，不支持经典蓝牙协议及其HFP……

市场上常见的蓝牙耳机方案：

03 免驱方案的突破：LE Audio与定制技术​

LE Audio：

主从设备均需要支持蓝牙5.2+，原因：

底层协议依赖​​
LE Audio 的核心功能依赖于蓝牙 5.2 规范中新增的 ​​LE 同步信道（LE Isochronous Channels）​​

。该信道提供了以下能力：

• ​​时间同步传输​​：确保音频流在多个设备间同步播放（如 TWS 耳机的左右耳）。
• ​​双向低延迟链路​​：支持 LC3 编解码器所需的实时音频传输（延迟可低至 20-50ms）。
• ​​广播音频（Auracast）​​：实现一对多的音频广播功能

物理层与协议栈限制​​

• 蓝牙 5.1 及更早版本缺乏 LE Isochronous Channels，​​无法建立 LE Audio 所需的同步音频链路​​。
• 若从机芯片仅支持蓝牙 5.1，即使软件模拟也无法实现系统级免驱音频传输

厂商定制方案的“伪免驱”​

• 广播音频技术​​：如歌尔股份的专利方案，BLE主机广播音频流，从机扫描后直接连接播放，​​无需配对​​。但需设备预装厂商SDK，严格意义上非系统级免驱
• ​​私有协议+虚拟声卡​​：
  • 方案：通过BLE传输压缩音频（如Opus），在主机端用​​虚拟声卡驱动​​解码（如STM32WB的USB音频输出）
  • 用户体验：设备显示为“USB麦克风”，但依赖​​预装驱动​​（非即插即用）

需设备预装厂商SDK

04 增加USB KEY作为中间传输器件

增加USB KEY作为中间传输器件是一种有效的折中方案，可实现系统级免驱音频传输

USB KEY角色​​：集成USB控制器+BLE从机芯片，实现协议转换：

• 接收BLE音频流 → 解码 → 通过USB接口输出为UAC（USB Audio Class）信号。

补充： 增加设备驱动方案

现有传输方案：HID、TSPP（已验证）、GATT