概念)
在无线音频的世界里，一场静默却深刻的革命正在进行。
它，就是LE Audio。
这不仅仅是一次技术迭代，而是从底层重新定义声音如何被创造、传输和体验的范式转移。其复杂性令人敬畏——它并非单一技术，而是一套精密的生态系统：全新的LC3编解码器以超凡效率重塑音质与功耗的平衡，多重串流音频让真无线立体声达到前所未有的稳定与同步，而音频广播功能则打破了“一对一”连接的百年窠臼，让声音如电台般自由播撒。
然而，正是这种复杂性，构成了我们必须深入学习它的不可辩驳的理由。未来的声音图景将由它绘制：从下一代真无线耳机、无障碍助听设备到公共场所的沉浸式音频导览、多语言广播，乃至元宇宙中清晰无缝的语音交互。不了解LE Audio，将意味着在即将到来的音频浪潮中失去对话的基石。
这不仅仅关乎技术本身，更关乎我们如何连接彼此，如何感知世界。让我们共同开启这段探索之旅，揭开LE Audio的复杂面纱，看清它为何必将成为未来数年里，每一个科技从业者、音频爱好者乃至普通用户都无法忽视的关键命题。
接下来的系列文章，我们将逐步拆解这座精妙的技术大厦。
同时我也录制了一系列的Le audio视频，有兴趣的可以咨询，我会带领你们入门Le audio！翻过大山，眼下皆是风景！！！
------------------------------------------------------------------------------------------------------------------------------------------
视频链接：https://item.taobao.com/item.htm?id=1001969040805&mi_id=000032T4qZX9WZoRwX6YbxlNUaZOfOI6XoxDx0jxsfnwlEc&spm=a21xtw.29178619.0.0
---------------------------------------------------------------------------------------------------------------------------------
一. 概念
1. 概念
BAP以及PACS/ASCS/BASS算是整个Le audio中的核心中的核心，在整个le audio的架构如下：
2. BAP角色介绍
另外，我们来介绍下BAP的角色，通过介绍BAP的角色来深化下PACS的概念
BAP定义了六种角色:
- 单播服务器(Unicast Server), 这个是gatt server端
- 单播客户端(Unicast Client)，这个是gatt client端
- 广播源(Broadcast Source)，这个对于gatt没有要求
- 广播接收器(Broadcast Sink)，这个是gatt sever端
- 广播助手(Broadcast Assistant),这个是gatt client端
- 扫描委托器(Scan Delegator)，这个是gatt server端
a.单播角色
单播音频使用两种BAP角色：单播服务器和单播客户端。
ⅰ.单播服务器(Unicast Server)
单播服务器发送广播(BLE advertisements)，以便单播客户端发现单播服务器并与之建立连接。
单播服务器对外发布属性，供单播客户端发现其支持的音频能力。
单播服务器对外发布属性，供单播客户端发现、配置和控制由单播服务器发布的音频流端点。
单播服务器对外发布其当前传输或接收单播音频流的可用性状态。
单播服务器接受建立包含一个或多个同步连接的同步组，用于传输单播音频流。
单播服务器可以终止同步连接。
ⅱ.单播客户端(Unicast Client)
单播客户端通过扫描广播来发现单播服务器，并与之建立连接。
单播客户端发现单播服务器传输或接收单播音频流的可用性。
单播客户端发现并使用单播服务器发布的属性，以确定单播服务器的音频能力及支持的音频角色。
单播客户端发现用于配置和控制单播服务器所发布的音频流端点的属性。
单播客户端配置并建立一个或多个同步组，每个组可包含一个或多个用于传输单播音频流的同步连接。
单播客户端可以终止同步连接。
b.广播角色
广播音频使用四种BAP角色：广播源、广播接收器、广播助手和扫描委托器。
ⅰ.广播源(Broadcast Source)
广播源配置并建立一个或多个同步广播组，每个组包含一个或多个用于传输广播音频流的同步广播流。
广播源发送描述广播音频流配置的数据。
广播源发送使设备能够发现和接收广播音频流的数据。
ⅱ.广播接收器(Broadcast Sink)
广播接收器发现描述广播音频流配置的数据。
广播接收器发现并接收广播音频流。
广播接收器对外发布其音频能力。
ⅲ.广播助手(Broadcast Assistant)
广播助手发现广播接收器的音频能力。
广播助手发现使设备能够发现和接收广播音频流的数据。
广播助手发现描述广播音频流配置的数据。
广播助手连接至扫描委托器，并将代表扫描委托器扫描到的数据（包括解密加密广播音频流所必需的广播代码）传输给扫描委托器。
广播助手扫描寻求协助的扫描委托器。
广播助手请求扫描委托器发现描述广播音频流的数据，并可请求与广播接收器同处一地的扫描委托器接收广播音频流。
ⅳ.扫描委托器(Scan Delegator)
扫描委托器寻找广播助手设备，代表其执行扫描任务。
扫描委托器接收广播助手代表其扫描并传输的数据，包括解密加密广播音频流所必需的广播代码。
我们来看看广播的各个角色的关系
二. 协议支持要求
其中各个协议跟角色的对应关系如下：
1. Unicast Server支持要求
单播服务器应实例化一个音频流控制服务(ASCS)。
单播服务器应实例化一个已发布的音频能力服务(PACS)。
a. PACS要求
若单播服务器支持音频接收端角色，则必须在包含一个或多个PAC记录的一个或多个接收端PAC特性中，披露音频接收端角色支持的所有音频能力设置。
若单播服务器支持音频发送端角色，则必须在包含一个或多个PAC记录的一个或多个发送端PAC特性中，披露音频发送端角色支持的所有音频能力设置。
b. ASCS要求
如果单播服务器支持音频接收端角色：
- 若单播服务器在
Sink Audio Locations特性值中设置了多于一个比特位为0b1，则该服务器必须支持接收多个音频通道。 - 若单播服务器支持接收多个音频通道，则其必须提供足够数量的
Sink ASE特性，以承载所支持的最高音频通道数量的音频数据。 - 在任一
Sink PAC特性中，若Supported_Audio_Channel_CountsLTV 结构的值大于 1，则表明该服务器支持Sink ASE的音频通道复用。
- 若不支持音频通道复用，则
Sink ASE的数量应大于或等于Sink Audio Locations特性值中设为0b1的比特位数。 - 若支持音频通道复用，则
Sink ASE的数量应大于或等于（Sink Audio Locations特性值中设为0b1的比特位数）除以（Supported_Audio_Channel_CountsLTV 中所支持的最高音频通道数）。
- 若不支持音频通道复用，则
如果单播服务器支持音频发送端角色：
- 若单播服务器在
Source Audio Locations特性值中设置了多于一个比特位为0b1，则该服务器必须支持发送多个音频通道。 - 若单播服务器支持发送多个音频通道，则其必须提供足够数量的
Source ASE特性，以承载所支持的最高音频通道数量的音频数据。 - 在任一
Source PAC特性中，若Supported_Audio_Channel_CountsLTV 结构的值大于 1，则表明该服务器支持Source ASE的音频通道复用。
- 若不支持音频通道复用，则
Source ASE的数量应大于或等于Source Audio Locations特性值中设为0b1的比特位数。 - 若支持音频通道复用，则
Source ASE的数量应大于或等于（Source Audio Locations特性值中设为0b1的比特位数）除以（Supported_Audio_Channel_CountsLTV 中所支持的最高音频通道数）。
- 若不支持音频通道复用，则
为了告知未连接的单播客户端本单播服务器是可连接的，并且可用于接收或发送特定上下文类型值的音频数据，单播服务器应发送包含服务数据 AD数据类型
- 定向通告（通告类型 =
0x01）意味着单播服务器可连接并且正在请求连接。 - 通用通告（通告类型 =
0x00）意味着单播服务器可连接但未请求连接。
2. Unicast client支持要求
对于unicast client的要求，其实就是对ASCS跟PACS的服务discovery以及特征的discovery
另外，对于audio capability的配置要求支持
三. LC3 codec集成
1. Generic Audio LTV介绍
a. Codec_Specific_Capabilities LTV Structures
这个就是特定的Codec的音频能力，其中LTV模型比较常见，就是length-type-valve哈·
Codec的音频能力包含以下几个方面：
- 支持的采样率
- 支持的帧间隔
- 支持的音频通道个数
- 支撑的每帧字节数
- 支持的每个SDU的帧数
这个非常好理解，就是想通信，肯定要协商参数吧？但是你不告知对方你支持哪些参数，怎么协商呢？所以这个就是告知对端支持哪些能力，这个类似于传统蓝牙AVDTP SEP(stream end point)的capability
支持的采样率
支持的帧间隔
支持的音频通道个数
支撑的每帧字节数
支持的每个SDU的帧数
b. Codec_Specific_Configuration LTV structures
采样率
帧间隔
音频通道分配
每帧字节
SDU中的帧
c. Metadata LTV structures
这个就是元数据，其中LTV模型比较常见，就是length-type-valve哈·
metadata包含以下几个方面：
- 首选音频场景(Preferred_Audio_Contexts)
- 流媒体音频场景(Streaming_Audio_Contexts)
- 程序场景(Program_Info)
- 语言(Language)
- CCID列表(CCID_List)
- 家长分级(Parental_Rating)
- 程序场景URI(Program_Info_URI)
- 扩展的Metadata(Extended_Metadata)
- 厂商自定义(Vendor_Specific)
- 音频活动状态(Audio_Active_State)
- 广播音频即时渲染标志(Broadcast_Audio_Immediate_Rendering_Flag)
- 辅助收听流(Assisted_Listening_Stream)
- 广播名称(Broadcast_Name)
首选音频场景(Preferred_Audio_Contexts)
有两个byte,其中场景有如下定义
Value | Label | Description |
0x0000 | Prohibited | Prohibited |
0x0001 | Unspecified | Identifies audio where the use case context does not match any other defined value, or where the context is unknown or cannot be determined. |
0x0002 | Conversational | Conversation between humans, for example, in telephony or video calls, including traditional cellular as well as VoIP and Push-to-Talk. |
0x0004 | Media | Media, for example, music playback, radio, podcast or movie soundtrack, or tv audio. |
0x0008 | Game | Audio associated with video gaming, for example gaming media; gaming effects; music and in-game voice chat between participants; or a mix of all the above. |
0x0010 | Instructional | Instructional audio, for example, in navigation, announcements, or user guidance. |
0x0020 | Voice Assistants | Man-machine communication, for example, with voice recognition or virtual assistants. |
0x0040 | Live | Live audio, for example, from a microphone where audio is perceived both through a direct acoustic path and through an LE Audio Stream. |
0x0080 | Sound Effects | Sound effects including keyboard and touch feedback; menu and user interface sounds; and other system sounds. |
0x0100 | Notifications | Notification and reminder sounds; attention-seeking audio, for example, in beeps signaling the arrival of a message. |
0x0200 | Ringtone | Alerts the user to an incoming call, for example, an incoming telephony or video call, including traditional cellular as well as VoIP and Push-to-Talk. |
0x0400 | Alerts | Alarms and timers; immediate alerts, for example, in a critical battery alarm, timer expiry or alarm clock, toaster, cooker, kettle, microwave, etc. |
0x0800 | Emergency Alarm | Emergency sounds, for example, fire alarms or other urgent alerts. |
流媒体音频场景(Streaming_Audio_Contexts)
其中场景如上，我们已经介绍过了
程序场景(Program_Info)
语言(Language)
3个byte的语言码，标准参考ISO 639-3, 比较长，我们不贴了，自己可以去网上查看下
CCID列表(CCID_List)
家长分级(Parental_Rating)
（用于标识媒体内容（如电影、游戏、电视节目）是否适合特定年龄段观众观看的内容分级或评级标签
程序场景URI(Program_Info_URI)
扩展的Metadata(Extended_Metadata)
厂商自定义(Vendor_Specific)
音频活动状态(Audio_Active_State)
广播音频即时渲染标志(Broadcast_Audio_Immediate_Rendering_Flag)
这个术语用于指示接收到的广播音频数据是否应被立即播放/渲染，而无需等待缓冲区填充或额外的同步处理。
辅助收听流(Assisted_Listening_Stream)
此术语特指为听力辅助设备（如助听器）优化传输的音频流，旨在帮助有听力障碍的用户更清晰地收听音频内容。
广播名称(Broadcast_Name)
2. LC3单播场景
LC3是一种单声道编解码器。单播客户端和一个或多个单播服务器可以通过不同方式发送和接收多声道的LC3编码音频数据。
下表展示了支持LC3的单播设备的典型音频配置。
虚线代表一个CIS（等时连接），该连接最多可传输两个单向的单播音频流（每个方向一个）。箭头代表一个可分配给音频定位的独立音频声道。指向右侧的箭头表示音频数据从单播客户端流向单播服务器上的接收端ASE；指向左侧的箭头表示音频数据从单播服务器上的发送端ASE流向单播客户端。
后缀为(ii)的音频配置使用一个单播客户端和两个单播服务器；表中所有其他音频配置均使用一个单播客户端和一个单播服务器。
所有包含两个接收端ASE和/或两个发送端ASE的多声道音频配置，均假设其传输或接收的音频声道对应不同的音频定位。若向不同的接收端ASE（无论位于同一单播服务器或不同单播服务器）发送两个包含相同音频定位声道的音频流，或从不同的发送端ASE（无论位于同一单播服务器或不同单播服务器）接收此类音频流
对于一对单播服务器中的单个单播服务器而言，下表后缀为(ii)的音频配置与其他行（例如，从一对单播服务器中单个服务器的视角看，音频配置6(ii)等同于音频配置1）的音频配置相同，若支持要求已在其他行定义，则该行以灰色填充。对于单播客户端而言，下表的每一行均定义了一个独立的音频配置，该配置以单个CIG（等时连接组）形式实现。
a. Audio Configuration 1
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | 单播服务端设备数量 |
单向 | 1 | 1 | 1 | 1 |
单播服务端产品形态举例: 不带麦克风的单声道耳机
b. Audio Configuration 2
传输方向 | CIS数量 | 音频流数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
单向 | 1 | 1 | 1 | 1 |
单播服务端产品形态举例: 单声道麦克风
c. Audio Configuration 3
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
双向 | 1 | 2 | 1 | 1 | 1 |
单播服务端产品形态举例: 含有一个麦克风的单声道耳机
d. Audio Configuration 4
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | 单播服务端设备数量 |
单向 | 1 | 1 | 2 | 1 |
单播服务端产品形态举例: 无麦克风的头戴式/挂脖式立体声耳机
e. Audio Configuration 5
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
双向 | 1 | 2 | 2 | 1 | 1 |
单播服务端产品形态举例: 含有一个麦克风的头戴式/挂脖式立体声耳机
f. Audio Configuration 6(i)
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量* | 单播服务端设备数量 |
单向 | 2 | 2 | 1 | 1 |
单播服务端产品形态举例: 无麦克风的头戴式/挂脖式立体声耳机
*单播服务端有两个Sink ASEs, 每个Sink ASE支持1个音频通道
g. Audio Configuration 6(ii)
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | 单播服务端设备数量 |
单向 | 2 | 2 | 1 | 2 |
单播服务端产品形态举例: 无麦克风的一对耳塞(左右耳)
unicast server 1跟2分别如下：
h. Audio Configuration 7(i)
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
双向 | 2 | 2 | 1 | 1 | 1 |
单播服务端产品形态举例: 含有一个麦克风的单声道耳机
i. Audio Configuration 7(ii)
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
双向 | 2 | 2 | 1 | 1 | 2 |
单播服务端产品形态举例: 一个麦克风和一个无麦克风的单声道耳机(耳麦产品组合)
Unicast Server 1
Unicast Server 2
j. Audio Configuration 8(i)
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量* | Source ASE音频通道数量 | 单播服务端设备数量 |
双向 | 2 | 3 | 1 | 1 | 1 |
单播服务端产品形态举例: 含有一个麦克风的头戴式或挂脖式立体声耳机
*单播服务端有两个Sink ASEs, 每个Sink ASE支持1个音频通道
k. Audio Configuration 8(ii)
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
双向 | 2 | 3 | 1 | 1 | 2 |
单播服务端产品形态举例: 有一边含有麦克风的TWS耳机
Unicast Server 1
Unicast Server 2
l. Audio Configuration 9(i)
传输方向 | CIS数量 | 音频流数量 | Source ASE音频通道数量* | 单播服务端设备数量 |
单向 | 2 | 2 | 1 | 1 |
单播服务端产品形态举例: 含有两个麦克风的产品(双麦)
*单播服务端有两个Source ASEs, 每个Source ASE支持1个音频通道
m. Audio Configuration 9(ii)
传输方向 | CIS数量 | 音频流数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
单向 | 2 | 2 | 1 | 2 |
单播服务端产品形态举例: 两个分立式麦克风
Unicast Server 1
Unicast Server 2
n. Audio Configuration 10
传输方向 | CIS数量 | 音频流数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
单向 | 1 | 1 | 2 | 1 |
单播服务端产品形态举例: 含有两个麦克风的产品(双麦)
o. Audio Configuration 11(i)
双向/双声道/两个CIS/一台单播服务端产品
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量* | Source ASE音频通道数量# | 单播服务端设备数量 |
双向 | 2 | 4 | 1 | 1 | 1 |
单播服务端产品形态举例: 含有两个麦克风的头戴式或挂脖式立体声耳机
*单播服务端有两个Sink ASEs, 每个Sink ASE支持1个音频通道
#单播服务端有两个Source ASEs, 每个Source ASE支持1个音频通道
p. Audio Configuration 11(ii)
传输方向 | CIS数量 | 音频流数量 | Sink ASE音频通道数量 | Source ASE音频通道数量 | 单播服务端设备数量 |
双向 | 2 | 4 | 1 | 1 | 2 |
单播服务端产品形态举例: TWS耳机，左右耳都带麦克风
Unicast Server 1
Unicast Server 2
四. Unicast audio streaming procedures
定义了在与支持PACS和ASCS的单播服务器通信时，单播客户端使用的流程。
单播音频流传输涉及一个单播客户端和一个或多个单播服务器。单播客户端配置编解码器参数，或使用单播服务器公开的当前编解码器参数。随后，单播客户端配置服务质量参数。接着，单播客户端启用一个音频流端点（ASE）和一个已连接的等时同步流（CIS），并可提供用于描述单播音频流或用于其他目的的元数据。
音频流端点（ASE）的音频角色由其特性UUID决定。接收端（Sink）ASE特性意味着对于该ASE，单播服务器处于音频接收（Audio Sink）角色，而单播客户端处于音频发送（Audio Source）角色。发送端（Source）ASE特性意味着对于该ASE，单播服务器处于音频发送角色，而单播客户端处于音频接收角色。如文献[6]第2.2节所述，如果描述和/或行为同等适用于两者，则术语"ASE特性"（或"ASE"）可互换指代接收端（Sink）ASE特性和发送端（Source）ASE特性；否则将按名称提及特性（或ASE）。
当某个ASE处于启用中（Enabling）状态时，对于该ASE处于音频接收角色的设备决定该ASE向流传输中（Streaming）状态的转换。在ASE处于启用中状态且已为其建立CIS时，并不禁止单播客户端和单播服务器传输音频数据。然而，在ASE进入流传输中状态之前，存在音频数据丢失的风险，因为单播音频流需待ASE进入流传输中状态才算建立。
ASE通过使用本节定义的流程进行控制。
包含以下流程
Procedure | Requirement | |
Audio role discovery | M | |
Audio capability discovery | O | |
ASE_ID discovery | M | |
Supported Audio Contexts discovery | O | |
Available Audio Contexts discovery | O | |
ASE Control operations | – | |
Codec configuration | M | |
QoS configuration | M | |
Enabling an ASE | M | |
Audio data path setup | M | |
Receiver Start Ready | C.1 | |
Updating Metadata | M | |
Disabling an ASE | M | |
Receiver Stop Ready | C.1 | |
Releasing an ASE | M | |
Audio data path removal | M | |
Released ASEs or LE ACL link loss | M | |
CIS loss | M | |
前面就是attribute discovery的流程，我们就不介绍了，我们来介绍下ASE control operation的介绍，在介绍特定的操作之前，我们先来看看状态机
1. ASCS ASE状态管理
ASE（音频流端点）的配置、控制和状态通过一个ASE状态机来描述。
该状态机的状态由服务器维护，并借助ASE特性与客户端共享。每个ASE在服务器上都有其独立的状态机实例。客户端可通过向ASE控制点特性写入指令来控制此状态机，或在某些情况下由服务器自主控制。客户端可通过观察ASE特性值的变化，来追踪ASE的状态和/或参数值变更。
Source ASE状态机如下：
Sink ASE状态机如下：
状态定义如下：
State (状态) | ASE状态值 | Description (描述) |
Idle (空闲) | 0x00 | ASE未应用任何编解码器配置或QoS配置 |
Codec Configured (编解码器已配置) | 0x01 | ASE已应用编解码器配置（可能由服务器自主配置或客户端请求）。服务器会公开其首选的QoS参数；但ASE尚未应用QoS配置 |
QoS Configured (QoS已配置) | 0x02 | ASE已应用编解码器配置和QoS配置。主机层应用的QoS配置可能与客户端控制器实际应用于CIS的配置不同。CIS可能存在，但ASE尚未与CIS耦合 |
Enabling (启用中) | 0x03 | ASE已应用编解码器配置和QoS配置，且客户端或服务器应用的任何元数据均已与该ASE关联。CIS可能存在，但ASE尚未与CIS耦合。若服务器或客户端在ASE进入流传输态之前开始发送音频数据，此状态存在音频数据包丢失风险 |
Streaming (流传输) | 0x04 | ASE已应用编解码器配置和QoS配置，且客户端或服务器应用的任何元数据均已与该ASE关联。ASE已与CIS耦合。作为音频接收端的设备已发起接收器启动就绪操作并成功完成，ASE已准备好接收或发送音频数据 |
Disabling (禁用中) | 0x05 | 仅适用于Source ASE。ASE已应用编解码器配置和QoS配置。为传输该ASE音频数据而建立的任何CIS可能保持连接或已断开，但ASE正从CIS解耦。先前应用的元数据在此状态下仍与ASE关联。在音频接收端设备成功完成接收器停止就绪操作之前，ASE仍保持可发送音频数据的状态 |
Releasing (释放中) | 0x06 | 为传输该ASE音频数据而建立的任何CIS正在断开或已断开。服务器可能缓存先前应用的编解码器配置，或自主选择缓存一种编解码器配置，或完全移除编解码器配置。先前应用的QoS配置不再有效。先前应用的元数据不再与ASE关联 |
– (保留) | 0x07–0xFF | RFU (保留供未来使用) |
我们来弄一个表格，展示下接收端ASE（Sink ASE）与发送端ASE（Source ASE）所允许的状态机转换。
若服务器检测到处于流传输态（Streaming）或禁用中态（Disabling）的ASE所对应的CIS发生链路丢失，则须立即将该ASE转换至QoS已配置态（QoS Configured）。若ASE处于除流传输态或禁用中态之外的任何状态时发生CIS链路丢失，均不应触发ASE状态机转换。
若服务器检测到处于任何状态的ASE所对应的低功耗蓝牙异步面向连接链路（LE-ACL）发生链路丢失，则须立即将该ASE转换至释放中态（Releasing），且服务器须遵循第5.9节所定义的要求。
若转换成功，ASE状态机须转换至“下一状态”，且所有适用参数须更新为其新值。
若转换失败，ASE状态机须保持在“当前状态”，且先前在当前状态下应用的所有参数均不得改变。
例如，若某个ASE处于空闲态（Idle）且服务器未能成功完成配置编解码器操作（Config Codec operation），则ASE状态机仍将保持在空闲态。
ASE类型 | 当前状态 | ASE控制操作 | 发起设备 | 下一状态 |
All | Idle | Config Codec | Client or server | Codec Configured |
All | Codec Configured | Config Codec | Client or server | Codec Configured |
All | Codec Configured | Release | Client or server | Releasing |
All | Codec Configured | Config QoS | Client only | QoS Configured |
All | QoS Configured | Config Codec | Client or server | Codec Configured |
All | QoS Configured | Config QoS | Client only | QoS Configured |
All | QoS Configured | Release | Client or server | Releasing |
All | QoS Configured | Enable | Client only | Enabling |
All | Enabling | Release | Client or server | Releasing |
All | Enabling | Update Metadata | Client or server | Enabling |
Source ASE | Enabling | Disable | Client or server | Disabling |
Sink ASE | Enabling | Disable | Client or server | QoS Configured |
Source ASE | Enabling | Receiver Start Ready | Client | Streaming |
Sink ASE | Enabling | Receiver Start Ready | Server | Streaming |
All | Streaming | Update Metadata | Client or server | Streaming |
Source ASE | Streaming | Disable | Client or server | Disabling |
Sink ASE | Streaming | Disable | Client or server | QoS Configured |
All | Streaming | Release | Client or server | Releasing |
Source ASE | Disabling | Receiver Stop Ready | Client only | QoS Configured |
Source ASE | Disabling | Release | Client or server | Releasing |
All | Releasing | Released (no caching) | Server only | Idle |
All | Releasing | Released (caching) | Server only | Codec Configured |
2. ASE Control operations
a. Codec configuration
要提交编解码器配置参数，单播客户端应发起配置编解码器（Config Codec）操作。
单播客户端仅应对处于空闲状态（Idle state）、编解码器已配置状态（Codec Configured state）或服务质量已配置状态（QoS Configured state）的音频流端点（ASE）发起配置编解码器操作。
当为某个ASE发起配置编解码器操作时，单播客户端仅应提交单播服务器支持的编解码器配置参数。
对于单播客户端发起的配置编解码器操作，单播服务器不应拒绝其所支持的编解码器配置参数。
单播客户端应通过接收ASE特性值的通知，或在ASE处于编解码器已配置状态时读取ASE特性值，来确定单播服务器的首选服务质量（QoS）范围参数值。
图示例展示了单播客户端为两个ASE发起配置编解码器操作。其中，ASE_ID[i]代表接收端（Sink）ASE，ASE_ID[j]代表发送端（Source）ASE。单播服务器通知包含配置编解码器操作成功响应的ASE控制点（ASE Control Point）特性。随后，单播服务器通知已过渡到编解码器已配置状态的两个ASE特性，从而公开单播服务器的编解码器配置参数及其首选的服务质量范围参数。
b. QoS configuration
c. Enabling an ASE
d. Updating unicast Audio Stream Metadata
e. Disabling an ASE
f. Releasing an ASE
g. Released ASEs or LE ACL link loss
四. Presentation delay and total system delay
按照BAP的规范，LE AUDIO音频总延时包括三个部分：Audio Processing Time，Transport Latency，Presentation Delay。如下图所示是播放音乐的示例图：
这里还有一个麦克风录音的总时延示例图：
Audio Processing Time：这个就是音频DSP获取音频数据到编解码处理完成的时间。
Transport Latency：这个就是传输时延。
Presentation Delay：这个时延就是为了多个接收端播放或发送端同步用的。
