1. 低功耗蓝牙音频能力协商的行业痛点
在蓝牙音频设备井喷式发展的今天,耳机、音箱、助听器等设备需要与手机、平板等音源设备建立连接时,面临一个基础但关键的问题:如何让双方快速、准确地识别彼此的音频编解码能力?传统蓝牙音频采用固定编解码方式(如SBC),导致高端设备无法发挥其LDAC、aptX HD等高清编解码优势,而低端设备又可能被迫接收无法处理的音频流。
这个问题的技术本质是能力发现机制的缺失。2016年蓝牙技术联盟(SIG)在蓝牙5.2版本中引入LE Audio架构时,专门设计了PACS(Published Audio Capabilities Service)服务作为解决方案。其实质是通过标准化服务声明,让设备在连接建立前就能互相"亮明身份"。
提示:PACS属于蓝牙GATT规范中的"通用属性配置文件"服务,必须配合蓝牙核心规范v5.2及以上版本使用。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. PACS服务架构深度解析
2.1 服务声明与特性定义
PACS作为GATT服务,其UUID为0x1850,包含三个核心特性:
-
Supported Audio Contexts(支持音频场景)
- UUID:
0x2BDE - 数据格式:16位位掩码(bitmask)
- 定义设备支持的音频使用场景,如媒体播放(0x0001)、通话(0x0002)、警报(0x0004)等
- UUID:
-
Available Audio Contexts(可用音频场景)
- UUID:
0x2BDF - 数据格式同Supported Audio Contexts
- 表示设备当前可用的场景(如关闭麦克风时通话场景不可用)
- UUID:
-
Sink PAC/Audio Locations(接收端能力)
- UUID:
0x2BE0(接收端)/0x2BE1(发送端) - 数据格式:TLV(Type-Length-Value)结构
- 包含编解码器类型、采样率、帧长度等关键参数
- UUID:
2.2 典型交互流程示例
当TWS耳机(接收端)与手机(发送端)建立连接时:
- 手机通过GATT发现服务,读取耳机的
Sink PAC特性 - 解析TLV数据获得支持的编解码列表(如[LC3, 48
