1、LE Audio介绍

1.1、LE Audio传输协议

2019年底，蓝牙官方组织SIG发布了蓝牙5.2版本的核心协议，其中增加了一个重要的特性---LE Audio。

蓝牙的应用协议都是从应用层到物理层完整包含的协议，LE Audio也不例外。但蓝牙5.2核心协议仅仅定义了蓝牙LE的链路层传输Audio的方式，上层协议以及完整的LE Audio规范迟迟未出，近日，蓝牙官方组织释放了LE Audio较为完整的规范文档。

1.2、LE Audio完整应用

本次Sig组织定义了如下规范和协议，这些规范协议连同核心协议组成了LE Audio的完整应用

Basic Audio Profile(BAP)

基础音频规范，LE Audio的关键规范，定义了各类角色以及每个角色需要支持的能力，以及如何使用如下各服务完成音频应用的传输。LE Audio支持点对点音频模式和广播音频模式，2种模式下，会使用不同的服务。

Published Audio Capabilities Service(PACS)

已发布音频能力服务，此服务定义了本设备支持的音频能力，包括但不限于支持的编解码器个数以及各编解码能力，通过此项服务，可获取设备的音频能力。

Audio Stream Control Service(ASCS)

音频流控制服务，此服务定义了一套操作指令，用于建立配置以及关闭音频流。

Broadcast Audio Scan Service(BASS)

广播音频扫描服务，此服务用于广播音频发布者告知周边接收器广播音频参数，这个服务仅在广播音频类

Low Complexity Comunication Codec(LC3)

用于LE Audio的音频编解码器，顾名思义，此编码器属于低复杂度的音频编码器。LC3编码器可选参数范围很大，应用范围从8KHz单声道语音到48KHZ多声道音乐均支持，同时相比经典蓝牙音频规范使用的编码器SBC，同码率下音质有很大的提升。

2、LE Audio详解

2.1、BAP规范

BAP规范作为LE Audio的基础音频规范，其位于如下蓝牙协议层。

BAP规范根据支持的点对点音频和广播音频，定义了如下角色

Unicast Role	Unicast Server	点对点音频从设备
Unicast Role	Unicast Client	点对点音频主设备
Broadcast Role	Broadcast Source	广播音频发射设备
	Broadcast Sink	广播音频接收设备
	Broadcast Assistant	广播音频协助设备
	Scan Delegator	广播音频扫描设备

每类角色支持的服务如下（注： X代表不支持，M代表必须支持，O代码可选支持）

BAP Role Service Role	Unicast Server	Unicast Client	Broadcast Source	Broadcast Sink	Scan Delegator	Broadcast Assistant
ASCS Client	X	M	X	X	X	X
ASCS Server	M	X	X	X	X	X
PACS Client	X	M	X	X	X	O
PACS Server	M	X	X	M	X	X
BASS Client	X	X	X	X	X	M
BASS Server	X	X	X	X	M	X

当2个设备处于对应角色时，即可通过BAP定义的操作步骤完成服务的连接以及音频传输服务。

以Unicast Server和Unicast Client为例，其步骤如下

Unicast Client通过GATT服务发现操作发现Unicast Server的PACS服务并得知音频参数。
Unicast Client通过GATT服务发现操作发现Unicast Server的ASCS服务并得知当前状态。

Unicast Client如发现其音频参数匹配且Server的状态处于IDLE状态，即可连接音频服务。
Unicast Client通过ASCS定义的操作码，配置音频编解码参数和音频传输参数，然后开启音频。

Unicast Client通过核心协议5.2定义的方式，根据配置参数，在链路层开启CIS音频传输流。
Unicast Sink通过ASCS操作码，通知Unicast Source已可接收音频。

Unicast Source开启LC3编解码器，并将编码后的音频流通过CIS传输到Unicast Sink。
Unicast Sink接收音频流，解码并播放。

2.2、PACS服务

PACS服务用于点对点音频，定义了设备的音频能力，其服务定义如下。

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Sink PAC	C.1	Read	Notify	Encryption required
Sink Audio Locations	C.2	Read	Notify, Write	Encryption required
Source PAC	C.1	Read	Notify	Encryption required
Source Audio Locations	C.3	Read	Notify, Write	Encryption required
Available Audio Contexts	M	Read, Notify	None	Encryption required
Supported Audio Contexts	M	Read	Notify	Encryption required

其中，Source PAC为音频发送能力属性，当设备支持音频发送时才需要定义，其格式如下：

Parameter	Size (Octets)	Description
Number_of_PAC_records	1	Number of PAC records, [i], for this characteristic
Codec_ID[i]	5	Octet 0: Coding_Format value of the [ith] PAC record. Coding_Format values are defined in Bluetooth Assigned Numbers. Octet 1–2: Company _ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF. Company_ID values are defined in Bluetooth Assigned Numbers. Octet 3–4: Vendor-specific codec_ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF.
Codec_Specific_Capabilities_Length[i]	1	Length of the Codec_Specific_Capabilities value of the [ith] PAC record. Shall be 0x00 if the Codec_Specific_Capabilities value of the [ith] PAC record is empty.
Codec_Specific_Capabilities[i]	Varies	Codec_Specific_Capabilities value of the [ith] PAC record.
Metadata_Length[i]	1	Length of the Metadata field of the [ith] PAC record. Shall be 0x00 if the Metadata value of the [ith] PAC record value is empty.
Metadata[i]	Varies	LTV-formatted Metadata applicable to the [ith] PAC record. Shall exist only if the value of the Metadata_Length field is not 0x00.

Sink PAC为音频接收能力属性，当设备支持音频接收时才需要定义，其格式如下：

Parameter	Size (Octets)	Description
Number_of_PAC_records	1	Number of PAC records, [i], in this characteristic.
Codec_ID[i]	5	Octet 0: Coding Format of the [ith] PAC record. Coding_Format values are defined in Bluetooth Assigned Numbers Octet 1–2: Company_ID value of the [ith] PAC record. Company_ID values are defined in Bluetooth Assigned Numbers Shall be 0x0000 if octet 0 is not 0xFF. Octet 3–4: Vendor-specific codec_ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF.
Codec_Specific_Capabilities_Length[i]	1	Length, in octets, of the Codec_Specific_Capabilities value of the [ith] PAC record. Shall be 0x00 if the Codec_Specific_Capabilities value of the [ith] PAC record is empty.
Codec_Specific_Capabilities[i]	Varies	Codec_Specific_Capabilities value of the [ith] PAC record.
Metadata_Length[i]	1	Length of the Metadata field of the [ith] PAC record. Shall be 0x00 if the Metadata value of the [ith] PAC record value is empty.
Metadata[i]	Varies	Length-type-value (LTV)-formatted Metadata applicable to the [ith] PAC record. Shall exist only if the value of the Metadata_Length field is not 0x00.

2.3、ASCS服务

ASCS服务用于音频控制，通过定义的一套操作码作交互，从而达到控制音频状态转移的目的。

ASCS的服务定义如下

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Sink ASE	C.1	Read, Notify	None	Encryption required
Source ASE	C.1	Read, Notify	None	Encryption required
ASE Control Point	M	Write, WriteWithoutResponse, Notify	None	Encryption required

2.4、BASS服务

BASS为广播音频扫描服务，用于告知广播音频的一些参数，属于辅助服务，其定义如下。

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Broadcast Audio Scan Control Point	M	Write, Write Without Response	None	Encryption required
Broadcast Receive State	M	Read, Notify	None	Encryption required

2.5、LC3编解码器

LC3编解码器用于LE Audio的音频编解码，与MP3，AAC类似，属于频域编码，编码效率远高于SBC子带编码，而10毫秒和7.5毫秒的短帧结构，对于音频延迟有较大改善。

LC3在频域上引入了SNS频域噪声整形，TNS时域噪声整形以及熵编码等技术，其中TNS等技术已用于AAC，这些技术对于音质有提升，整个编码过程如下：

解码是编码的逆过程，如下：

3、LE Audio支持展望

LE Audio作为一个非常重要的特性，发布至今除少量demo仍未见应用。大规模普及仍依赖于操作系统厂商是否支持，诸如苹果的IOS以及谷歌的Android，从目前的进展(IOS14以及Android11)来看，仍未看到有支持LE Audio。

但翻看AOSP的代码，在Android12(android-s-beta版)上，已能发现LE Audio的痕迹，如下

从目前的代码完整度来看，仍不算完整功能支持，预计在Android12上会完善并开始应用，等手机支持后，相信会有厂商推出支持LE Audio的耳机。

但音频应用属于一个通用应用，苹果以及其他操作系统诸如微软的windows的支持也极其重要，从这个角度讲，LE Audio要大规模普及可能仍需要时间。

低功耗蓝牙LE Audio Profile 详细介绍相关推荐

第3章-蓝牙®LE audio新概念
机器翻译结果,仅用于学习,不喜勿喷,原文档链接. 为了给设计师提供他们需要的灵活性,新的蓝牙LE audio规范引入了一些重要的新概念.在本章中,我们将看看它们的作用以及为什么需要它们.由于这些特性与 ...
蓝牙技术｜AirPods Pro 2 支持蓝牙 LE Audio 技术带来的 5 大好处
在 2020 年,蓝牙 5.2 引入支持新的 LE Audio 音频规范.至少有两名苹果员工被列为 LE Audio 开发的参与者,苹果很可能会采用该规范以用于未来的设备. 根据蓝牙 SIG 数据库中 ...
蓝牙技术|了解蓝牙LE Audio的Auracast广播音频
蓝牙LE Audio,这是在2020年年初宣布,阐明定义一个新的方法或架构来满足这些要求,使未来20年无线音频的创新.允许开发人员构建与Classic Audio(使用BR / EDR)相同类型的产品 ...
蓝牙LE Audio的关键-LC3技术
LE Audio简介在过去的二十年中,自成立以来,蓝牙技术已成为去到解决方案对于绝大多数的无线音频流应用.如果您曾经通过头戴式耳机或汽车的信息娱乐系统无线听音乐,那么您很可能已经使用了蓝牙技术. 蓝 ...
蓝牙5.2新特性及低功耗蓝牙音频（LE Audio）解读
2020年1月6日蓝牙特别兴趣小组(SIG)宣布了新的蓝牙核心规范CoreSpec5.2,其中最引人注目的是下一代蓝牙音频LE Audio的颁布.LE Audio不仅支持连接状态及广播状态下的立体声 ...
一文看懂最新蓝牙5.2 LE Audio技术如何打破经典蓝牙音频垄断地位
2020年1月7日,在美国拉斯维加斯举办的CES2020展会上,蓝牙技术联盟(Bluetooth Special Interest Group,简称SIG)宣布即将发布新一代蓝牙音频技术标准-低功耗音 ...
第2章-Bluetooth® LE audio架构
机器翻译结果,仅用于学习,不喜勿喷,原文档链接. 蓝牙spec开发遵循一个明确定义的过程.它从新工作提案开始,该提案开发用例并评估市场对任何新功能的需求.新工作提案通常由一个小型研究小组生成,该小组由 ...
Android 上的低功耗蓝牙实践
转载自:https://www.race604.com/android-ble-in-action/ 我今天分享的主题是 Android 上低功耗蓝牙的实践.这个主题比较小众.我在过去的一年多的时间里 ...
一文看懂BT5.2 LE Audio新特性
---------------------------------------------------------------------------------------------------- ...

低功耗蓝牙LE Audio Profile 详细介绍