在无线音频的世界里一场静默却深刻的革命正在进行。它就是LE Audio。这不仅仅是一次技术迭代而是从底层重新定义声音如何被创造、传输和体验的范式转移。其复杂性令人敬畏——它并非单一技术而是一套精密的生态系统全新的LC3编解码器以超凡效率重塑音质与功耗的平衡多重串流音频让真无线立体声达到前所未有的稳定与同步而音频广播功能则打破了“一对一”连接的百年窠臼让声音如电台般自由播撒。然而正是这种复杂性构成了我们必须深入学习它的不可辩驳的理由。未来的声音图景将由它绘制从下一代真无线耳机、无障碍助听设备到公共场所的沉浸式音频导览、多语言广播乃至元宇宙中清晰无缝的语音交互。不了解LE Audio将意味着在即将到来的音频浪潮中失去对话的基石。这不仅仅关乎技术本身更关乎我们如何连接彼此如何感知世界。让我们共同开启这段探索之旅揭开LE Audio的复杂面纱看清它为何必将成为未来数年里每一个科技从业者、音频爱好者乃至普通用户都无法忽视的关键命题。接下来的系列文章我们将逐步拆解这座精妙的技术大厦。同时我也录制了一系列的Le audio视频有兴趣的可以咨询我会带领你们入门Le audio翻过大山眼下皆是风景------------------------------------------------------------------------------------------------------------------------------------------视频链接https://item.taobao.com/item.htm?id1001969040805mi_id000032T4qZX9WZoRwX6YbxlNUaZOfOI6XoxDx0jxsfnwlEcspma21xtw.29178619.0.0Le Audio文章目录还在为蓝牙BLE Audio的学习苦恼吗安排下让你一文彻底了解Le Audio蓝牙低功耗音频的技术-CSDN博客---------------------------------------------------------------------------------------------------------------------------------BAPBasic Audio ProfileUnicast Audio Streaming Procedures共包含15个主要步骤。Unicast Client和Unicast Server的总步骤几乎相同区别仅在于角色定义不同一个是控制方一个是被控方。这个的前提是我们已经在前面介绍了服务discovery, 拿LE_Audio_BAP_unicast_server.btt 这个btsnoop举例做完这些primary service的服务后client就已经生成serer端的服务table表了如下(沿用btsnoop序号不区分十进制/十六进制)服务开始句柄服务结束句柄服务19GATT(通用属性协议)0x1428GAP(通用访问协议)0x2842TMAP(电话媒体音频服务)0x2857CSIS(识别组服务)0x5696VCS(音量控制服务)0x61100MICS(麦克风输入服务)0x65115CAS(通用音频服务)0x74134PACS(发布音频能力服务)0x8765535ASCS(音频流控制服务)其中红色就是我们主要介绍的两个服务也就是单播主要用到的为了更好的理解后面的内容我们先列举出来PACS以及ASCS服务的特征。PACS特性名称必需属性可选属性安全权限Sink PAC信宿 PACRead读取Notify通知需加密Sink Audio Locations信宿音频位置Read读取Notify, Write通知写入需加密Source PAC信源 PACRead读取Notify通知需加密Source Audio Locations信源音频位置Read读取Notify, Write通知写入需加密Available Audio Contexts可用音频场景Read, Notify读取通知None无需加密Supported Audio Contexts支持音频场景Read读取Notify通知需加密ASCS特性名称必需属性可选属性安全权限接收端ASESink ASE读、通知Read, Notify无None需要加密发送端ASESource ASE读、通知Read, Notify无None需要加密ASE控制点ASE Control Point写、无响应写、通知Write, WriteWithoutResponse, Notify无None需要加密一. Audio role discovery蓝牙设备比如手机、耳机在建立连接后客户端通常是发起连接的设备如手机需要知道对方服务器如耳机到底能做“音频源Source”还是“音频接收器Sink”。音频接收器Sink负责播放声音比如耳机、音箱。音频源Source负责提供声音比如手机、音乐播放器。这段规范给出了具体的发现方法客户端不用依赖设备名称或猜测而是通过查找对方暴露的GATT 特征characteristics来判断。如果服务器提供了Sink 相关的特征如 Sink PAC、Sink Audio Locations、Sink ASE就说明它支持Sink 角色。如果服务器提供了Source 相关的特征如 Source PAC、Source Audio Locations、Source ASE就说明它支持Source 角色。其中PACPublished Audio Capabilities描述了设备的音频能力支持的编解码器、采样率、帧时长等。Audio Locations表示音频通道的位置如左耳、右耳、立体声等。ASEAudio Stream Endpoint是实际用于建立和配置音频流的端点。这种设计的好处是客户端可以清晰地、通过标准化的属性发现对方的功能从而决定如何建立单播音频流例如手机作为 Source 向耳机 Sink 发送音乐。一个设备也可能同时支持两种角色比如一个带麦克风的耳机既是 Sink 播放音乐又是 Source 发送麦克风音频。1. PACS进行sink/source PAC/audio location特征discovery2. ASCS进行sink/source ASE特征discovery二. Audio capability discovery这小节进一步解释了BAP Unicast中PACPublished Audio Capabilities和Audio Locations的作用核心是区分“强制支持”和“可选扩展能力”的发现方式。存在即表明支持强制能力只要 Unicast Server 暴露了Sink PAC特征就说明它一定能接收并解码那些音频编码配置比如某个基本的编解码器、采样率、帧时长等。类似地暴露Source PAC就说明它能用那些强制配置发送音频数据。读取值才能发现可选/扩展能力如果 Client 想利用非强制的能力例如更高规格的编解码、上层协议定义的新能力、或者厂商私有的特殊配置就需要主动读取 Sink PAC 或 Source PAC 特征的值从返回的数据里解析出对方还额外支持哪些东西。也就是说PAC 特征的存在只承诺了“基本款”具体支持哪些“豪华配置”要读值才知道。Audio Locations 独立表示声道位置Sink Audio Locations描述 Server 作为接收端时其各个声道在空间中的位置例如左耳、右耳、中央、环绕等。Client 读这个值来决定如何分配音频流到对应声道。Source Audio Locations类似地描述 Server 作为源端时它的麦克风或音频输入通道的物理位置例如左前、右前等。总结一条主线逻辑发现特征 → 确认角色Sink/Source及强制能力读取特征值 → 获取扩展能力 声道位置信息这种分层设计既保证了不同厂商设备能“开箱即连”又留下了充分的扩展空间无需修改规范就能引入新的音频能力。1. Sink PAC/Audio Location读取2. Source PAC/Audio Location读取三. Supported/Available Audio Contexts discovery本小节讲的是Supported Audio Contexts支持的音频上下文及其与Available Audio Contexts的关系还包含一个关于向后兼容的特殊规则。核心概念Supported ≠ AvailableSupported Audio Contexts表示设备硬件/固件能力上支持哪些 Context Type例如音乐、通话、游戏等。这是一个静态或半静态的属性不会因为当前正在使用而改变。Available Audio Contexts之前 5.5 节表示设备当前在这个连接中空闲可以再接受哪些类型的音频流。这是一个动态状态。两者的约束关系规范里明确禁止Server 不能在Available_Sink_Contexts或Available_Source_Contexts中把某个 bit 设为 1除非它在对应的Supported_Sink_Contexts/Supported_Source_Contexts中已经将该 bit 设为 1。也就是说可用集合必须是支持集合的子集。这是显然的——你不支持某种类型就不可能可用。Client 读取 Supported 的目的Client 读取 Supported Audio Contexts是为了知道对方到底支持哪些类型这可以帮助 Client 做出更合理的决策。例如如果对方不支持“游戏”上下文Client 就不会尝试为游戏建立流。或者在多个可用类型中Client 可以优先选择双方都支持的类型。特殊规则向后兼容时的例外规范里有一段看似矛盾的话如果 Client 发现 Server 不支持某个 Context Type那么 Client仅出于向后兼容原因可以尝试建立一个本来要用于该类型的音频流但此时 Client 必须把 Context Type 改为 Unspecified未指定。为什么会有这个规则因为早期的 BAP 版本或某些旧设备可能没有实现 Supported Audio Contexts 特征或者实现的方式不完整。当一个新 Client 遇到一个旧 Server 时如果 Client 严格遵循“不支持就不发起”可能会导致无法建立连接——而实际上旧设备是可以工作的只是它没有正确声明支持。向后兼容的操作方式Client 打算建立一个“通话”流但读到的 Supported 里没有“通话”。Client 可以降级仍然尝试建立流但在建流时将 Context Type 字段设为Unspecified0x00。这样做相当于忽略上下文类型只建立基本的音频传输。旧设备能理解Unspecified从而保持互通。与 Available 的关系因为 Available 的 bit 只能来自于 Supported 的子集所以如果一个 Context Type 不在 Supported 中那么它在 Available 中永远不可能为 1。因此 Client 根本不需要去读 Available 就知道对方不可能提供该类型的可用性。小结特征含义变化性用途Supported Audio Contexts设备能力上支持哪些音频场景静态判断能否兼容决定是否降级Available Audio Contexts当前连接中空闲可用的场景动态决定现在能否建流而那个“向后兼容”规则实际上是一个逃生舱口当新协议遇到旧设备时放弃语义精确性退回最基本的Unspecified保证能通。这是一种很典型的蓝牙规范设计思路。四. ASCS状态流转状态流转我们已经有一系列的文章介绍我们就不重复了直接列举下文章标题文章链接Le Audio ASCS config Codec operation流程介绍Le Audio ASCS config Codec operation流程介绍-CSDN博客Le Audio ASCS config QoS operation流程介绍Le Audio ASCS config QoS operation流程介绍-CSDN博客Le Audio ASCS enable operation流程介绍Le Audio ASCS enable operation流程介绍-CSDN博客Le Audio ASCS receive start ready operation流程介绍Le Audio ASCS receive start ready operation流程介绍-CSDN博客Le Audio ASCS Disable operation流程介绍Le Audio ASCS Disable operation流程介绍-CSDN博客Le Audio ASCS Receive Stop Ready operation流程介绍Le Audio ASCS Receive Stop Ready operation流程介绍-CSDN博客Le Audio ASCS Update Metadata operation流程介绍Le Audio ASCS Update Metadata operation流程介绍-CSDN博客Le Audio ASCS release/released operation流程介绍Le Audio ASCS release/released operation流程介绍-CSDN博客