在无线音频的世界里，一场静默却深刻的革命正在进行。
它，就是LE Audio。
这不仅仅是一次技术迭代，而是从底层重新定义声音如何被创造、传输和体验的范式转移。其复杂性令人敬畏------它并非单一技术，而是一套精密的生态系统：全新的LC3编解码器以超凡效率重塑音质与功耗的平衡，多重串流音频让真无线立体声达到前所未有的稳定与同步，而音频广播功能则打破了"一对一"连接的百年窠臼，让声音如电台般自由播撒。
然而，正是这种复杂性，构成了我们必须深入学习它的不可辩驳的理由。未来的声音图景将由它绘制：从下一代真无线耳机、无障碍助听设备到公共场所的沉浸式音频导览、多语言广播，乃至元宇宙中清晰无缝的语音交互。不了解LE Audio，将意味着在即将到来的音频浪潮中失去对话的基石。
这不仅仅关乎技术本身，更关乎我们如何连接彼此，如何感知世界。让我们共同开启这段探索之旅，揭开LE Audio的复杂面纱，看清它为何必将成为未来数年里，每一个科技从业者、音频爱好者乃至普通用户都无法忽视的关键命题。
接下来的系列文章，我们将逐步拆解这座精妙的技术大厦。
同时我也录制了一系列的Le audio视频，有兴趣的可以咨询，我会带领你们入门Le audio！翻过大山，眼下皆是风景！！！
一. 概念
1. 概念
音频能力发布服务(PACS)是低功耗蓝牙音频(LE Audio)中定义的用于展示音频设备的音频相关能力的技术规范。任何接受建立单播(Unicast)音频流或接收广播(Broadcast)音频流的设备均可通过支持PACS向客户端设备(例如手机)展示其支持的音频能力范围。例如音箱、耳机、助听器和麦克风
PACS服务展示设备支持的一个或多个音频能力和音频类型。音频能力通过PAC记录来呈现，PAC记录包含与音频编解码(Codec)相关的参数和元数据，PAC记录不区分单播音频流和广播音频流；音频类型(Audio Context)通过特定的特性值来呈现，音频类型用于确定设备是否接受特定类型音频的单播音频流，客户端不得向设备单播其不支持的音频类型。
PACS在整个Le audio的架构如下：
BAP属于GATT client端，PACS/ASCS/BASS属于GATT server端, 一般这4个协议配合使用！
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)，以便单播客户端发现单播服务器并与之建立连接。
单播服务器对外发布属性，供单播客户端发现其支持的音频能力。
单播服务器对外发布属性，供单播客户端发现、配置和控制由单播服务器发布的音频流端点。
单播服务器对外发布其当前传输或接收单播音频流的可用性状态。
单播服务器接受建立包含一个或多个同步连接的同步组，用于传输单播音频流。
单播服务器可以终止同步连接。
其中PACS定义在unicast server端
ⅱ. 单播客户端( Unicast Client**)**
单播客户端通过扫描广播来发现单播服务器，并与之建立连接。
单播客户端发现单播服务器传输或接收单播音频流的可用性。
单播客户端发现并使用单播服务器发布的属性，以确定单播服务器的音频能力及支持的音频角色。
单播客户端发现用于配置和控制单播服务器所发布的音频流端点的属性。
单播客户端配置并建立一个或多个同步组，每个组可包含一个或多个用于传输单播音频流的同步连接。
单播客户端可以终止同步连接。
b. 广播角色
广播音频使用四种BAP角色：广播源、广播接收器、广播助手和扫描委托器。
ⅰ. 广播源(Broadcast Source)
广播源配置并建立一个或多个同步广播组，每个组包含一个或多个用于传输广播音频流的同步广播流。
广播源发送描述广播音频流配置的数据。
广播源发送使设备能够发现和接收广播音频流的数据。
ⅱ. 广播接收器(Broadcast Sink)
广播接收器发现描述广播音频流配置的数据。
广播接收器发现并接收广播音频流。
广播接收器对外发布其音频能力。
ⅲ. 广播助手(Broadcast Assistant)
广播助手发现广播接收器的音频能力。
广播助手发现使设备能够发现和接收广播音频流的数据。
广播助手发现描述广播音频流配置的数据。
广播助手连接至扫描委托器，并将代表扫描委托器扫描到的数据（包括解密加密广播音频流所必需的广播代码）传输给扫描委托器。
广播助手扫描寻求协助的扫描委托器。
广播助手请求扫描委托器发现描述广播音频流的数据，并可请求与广播接收器同处一地的扫描委托器接收广播音频流。
ⅳ. 扫描委托器(Scan Delegator)
扫描委托器寻找广播助手设备，代表其执行扫描任务。
扫描委托器接收广播助手代表其扫描并传输的数据，包括解密加密广播音频流所必需的广播代码。
我们来看看广播的各个角色的关系
c. BAP单播对于PACS要求
从这张图比较容易理解哈· unicast server需要PACS，unicast client端需要 PACS client端(也就是BAP)
另外，下图是要求支持的格式
d. BAP广播对于PACS要求
从这张图比较容易理解哈· broadcast sink需要PACS，broadcast assistant端可能需要 PACS client端(也就是BAP)
另外，下图是要求支持的格式
3. 特征属性
|---------------------------------|--------|--------------------|---------------------|----------|
| 特性名称 | 要求 | 必需属性 | 可选属性 | 安全权限 |
| Sink PAC 信宿 PAC | C.1 | Read 读取 | Notify 通知 | 需加密 |
| Sink Audio Locations 信宿音频位置 | C.2 | Read 读取 | Notify, Write 通知，写入 | 需加密 |
| Source PAC 信源 PAC | C.1 | Read 读取 | Notify 通知 | 需加密 |
| Source Audio Locations 信源音频位置 | C.3 | Read 读取 | Notify, Write 通知，写入 | 需加密 |
| Available Audio Contexts 可用音频场景 | M | Read, Notify 读取，通知 | None 无 | 需加密 |
| Supported Audio Contexts 支持音频场景 | M | Read 读取 | Notify 通知 | 需加密 |
其中PACS的primary service的UUID为
VOCS包含的服务属性的UUID为：
二. 特征介绍
在介绍这些属性之前，我们来介绍下一些概念，方便后续的理解
1. 属性中用到的概念
a. Codec_Specific_Capabilities LTV Structures
这个就是特定的Codec的音频能力，其中LTV模型比较常见，就是length-type-valve哈·
Codec的音频能力包含以下几个方面：
- 支持的采样率
- 支持的帧间隔
- 支持的音频通道个数
- 支撑的每帧字节数
- 支持的每个SDU的帧数
这个非常好理解，就是想通信，肯定要协商参数吧？但是你不告知对方你支持哪些参数，怎么协商呢？所以这个就是告知对端支持哪些能力，这个类似于传统蓝牙AVDTP SEP(stream end point)的capability
支持的采样率
支持的帧间隔
支持的音频通道个数
支撑的每帧字节数
支持的每个SDU的帧数
b. 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. 人与人之间的对话，例如在电话或视频通话中，包括传统蜂窝网络以及VoIP和对讲。 |
| 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. 现场音频，例如来自麦克风的音频，该音频既通过直接声学路径也通过LE音频流被感知。 |
| 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. 提醒用户有来电的音频，例如来电的电话或视频呼叫，包括传统蜂窝网络以及VoIP和对讲。 |
| 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)
c. Audio location
音频位置，定义如下：
|-----------------|-------------------------------------------------------------|
| Value 值 | Audio Location 音频位置 |
| 0x00000000 | Mono Audio (no specified Audio Location) 单声道音频（未指定音频位置） |
| 0x00000001 | Front Left 前左 |
| 0x00000002 | Front Right 前右 |
| 0x00000004 | Front Center 前中 |
| 0x00000008 | Low Frequency Effects 1 低频效果1 |
| 0x00000010 | Back Left 后左 |
| 0x00000020 | Back Right 后右 |
| 0x00000040 | Front Left of Center 中前左 |
| 0x00000080 | Front Right of Center 中前右 |
| 0x00000100 | Back Center 后中 |
| 0x00000200 | Low Frequency Effects 2 低频效果2 |
| 0x00000400 | Side Left 侧左 |
| 0x00000800 | Side Right 侧右 |
| 0x00001000 | Top Front Left 上前左 |
| 0x00002000 | Top Front Right 上前右 |
| 0x00004000 | Top Front Center 上前中 |
| 0x00008000 | Top Center 上中 |
| 0x00010000 | Top Back Left 上后左 |
| 0x00020000 | Top Back Right 上后右 |
| 0x00040000 | Top Side Left 上侧左 |
| 0x00080000 | Top Side Right 上侧右 |
| 0x00100000 | Top Back Center 上后中 |
| 0x00200000 | Bottom Front Center 下前中 |
| 0x00400000 | Bottom Front Left 下前左 |
| 0x00800000 | Bottom Front Right 下前右 |
| 0x01000000 | Front Left Wide 前左宽 |
| 0x02000000 | Front Right Wide 前右宽 |
| 0x04000000 | Left Surround 左环绕 |
| 0x08000000 | Right Surround 右环绕 |
2. Sink PAC
Sink就是音频接收的概念，类似于传统蓝牙的A2DP sink!
Sink PAC特性用于在服务器支持接收音频数据时，发布PAC记录。
当服务器支持接收音频数据时，实现方式可选择将全部支持的PAC记录置于单一Sink PAC特性内，或使用多个Sink PAC特性发布。
Sink PAC特性的格式定义见表。
|---------------------------------------------------------|----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Parameter 参数 | Size | Description 描述 |
| Number_of_PAC_records PAC记录数量 | 1 | 该特性中PAC记录的数目[i]。应≥1。 |
| Codec_ID[i] 编解码器ID[i] | 5 | 字节0：[第i条]PAC记录的编码格式值。编码格式值定义在蓝牙分配号码[1]的主机控制器接口部分。 
字节1--2：[第i条]PAC记录的公司ID值。若字节0不是0xFF，则该值应为0x0000。 字节3--4：[第i条]PAC记录的供应商特定编解码器ID值。若字节0不是0xFF，则该值应为0x0000。 |
| Codec_Specific_Capabilities_Length[i] 编解码器特定能力长度[i] | 1 | [第i条]PAC记录的Codec_Specific_Capabilities值的长度（字节）。如果[第i条]PAC记录的Codec_Specific_Capabilities值为空，则应为0x00。 |
| Codec_Specific_Capabilities[i] 编解码器特定能力[i] | 可变 | [第i条]PAC记录的Codec_Specific_Capabilities值。 这个在assigned number中，LTV(length-type-length)的模型,这个在前面已经介绍过了，可以参考 |
| Metadata_Length[i] 元数据长度[i] | 1 | [第i条]PAC记录的元数据字段的长度。如果[第i条]PAC记录的元数据值为空，则应为0x00。 |
| Metadata[i] 元数据[i] | 可变 | 适用于[第i条]PAC记录的长度-类型-值格式的元数据。仅当Metadata_length字段的值不为0x00时才存在。这个在前面已经介绍过了，可以参考 |
可以看到这个里面只有一个record, 我们来分别解析下
Codec_ID: 编解码的ID，可以看到是LC3
下面我们来看看Capability
sample rate:
supported frame duration:
Audio channel count:
Support octets per codec frame:
Max supported codec frames per PDU
3. Sink Audio Locations
Sink音频位置特性用于在服务器支持接收音频数据时，对外发布其所支持的音频位置。
Sink音频位置特性的格式定义如下：
值是一个4个byte的内容，我们在前面已经介绍了！
4. Source PAC
Source就是音频发送的概念，类似于传统蓝牙的A2DP Source!
Source PAC特性用于在服务器支持传输音频数据时，发布PAC记录。
当服务器支持传输音频数据时，实现方式可选择将全部支持的PAC记录置于单一信源PAC特性内，或使用多个信源PAC特性发布。
Source PAC特性的格式跟Sink一样，定义见表。
|---------------------------------------------------------|----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Parameter 参数 | Size | Description 描述 |
| Number_of_PAC_records PAC记录数量 | 1 | 该特性中PAC记录的数目[i]。应≥1。 |
| Codec_ID[i] 编解码器ID[i] | 5 | 字节0：[第i条]PAC记录的编码格式值。编码格式值定义在蓝牙分配号码[1]的主机控制器接口部分。 字节1--2：[第i条]PAC记录的公司ID值。若字节0不是0xFF，则该值应为0x0000。 字节3--4：[第i条]PAC记录的供应商特定编解码器ID值。若字节0不是0xFF，则该值应为0x0000。 |
| Codec_Specific_Capabilities_Length[i] 编解码器特定能力长度[i] | 1 | [第i条]PAC记录的Codec_Specific_Capabilities值的长度（字节）。如果[第i条]PAC记录的Codec_Specific_Capabilities值为空，则应为0x00。 |
| Codec_Specific_Capabilities[i] 编解码器特定能力[i] | 可变 | [第i条]PAC记录的Codec_Specific_Capabilities值。 这个在assigned number中，LTV(length-type-length)的模型,这个在前面已经介绍过了，可以参考 |
| Metadata_Length[i] 元数据长度[i] | 1 | [第i条]PAC记录的元数据字段的长度。如果[第i条]PAC记录的元数据值为空，则应为0x00。 |
| Metadata[i] 元数据[i] | 可变 | 适用于[第i条]PAC记录的长度-类型-值格式的元数据。仅当Metadata_length字段的值不为0x00时才存在。这个在前面已经介绍过了，可以参考 |
5. Source Audio Locations
Source音频位置特性用于在服务器支持传输音频数据时，对外发布其所支持的音频位置。
Source音频位置特性的格式定义如下：
值是一个4个byte的内容，我们在前面已经介绍了！
6. Available Audio Contexts
可用音频上下文特征用于指示服务器在接收和/或发送仅与特定上下文类型关联的单播音频数据时的可用性状态。
可用音频上下文特征格式的定义详见表
音频场景的值我们已经在前面介绍过了，所以就不再赘述了
7. Supported Audio Contexts
支持的音频上下文特征展示了服务器对接收和/或发送与特定上下文类型关联的单播音频数据和/或广播音频数据的支持能力。
该特征的值使客户端能够判断服务器是否支持某个特定的上下文类型，这有别于服务器接收和/或发送 与该上下文类型关联的音频数据的当前可用性（后者由"可用音频上下文特征"的值定义）。
支持的音频上下文特征格式详见表。
音频场景的值我们已经在前面介绍过了，所以就不再赘述了
