蓝牙核心规范（V5.4）11.2-LE Audio 笔记之LE Auido架构

专栏汇总网址：蓝牙篇之蓝牙核心规范学习笔记（V5.4）汇总_蓝牙核心规范中文版_心跳包的博客-CSDN博客

爬虫网站无德，任何非CSDN看到的这篇文章都是盗版网站，你也看不全。认准原始网址。！！！

蓝牙LE音频架构是分层构建的，就像之前的每个蓝牙规范一样。这在下图中得到了说明，该图显示了与蓝牙LE Auido有关的主要新规范块（以灰色或点划线表示现有的关键规范）。

我们底层的核心层（Core）包含无线电和链路层（统称为控制器），负责通过空中发送蓝牙数据包。在它的上方为主机层，该层负责向底层核心层发出关于某个特定应用程序应当执行的任务的指令。控制器与主机之间的这种分工具有深远的历史渊源，它反映了蓝牙无线电设备曾被封装在USB驱动器或PCMCIA卡中的时代，那时候主机作为PC上的一个软件应用程序而存在。然而，现如今主机和控制器通常都被集成在单一芯片之中。

主机中包含一个称为通用音频框架（GAF）的新结构，它是一个音频中间件，包含被多个音频应用程序使用的所有通用功能。核心和GAF是蓝牙LE音频的核心部分，提供了很大的灵活性。在堆栈的顶部，有所谓的顶级配置文件，它们将特定于应用程序的信息添加到GAF规范中。

在传统的蓝牙配置文件中，通常只有一个客户端和一个服务器，所有的描述都在配置文件规范中。但在蓝牙低功耗音频（Bluetooth LE Audio）中，多对一的拓扑结构更为常见，尤其是在音量控制和广播源选择等功能中，一个用户可以拥有多个实现配置文件规范的设备作为客户端。

在大多数情况下，这些设备按照先到先得的原则进行操作。由于蓝牙低功耗音频可以使用许多不同的控制配置文件，这就需要对核心（Core）进行EATT增强。配置文件和服务使用属性协议（Attribute Protocol，ATT）进行通信，但ATT假设一次只发生一个命令。如果有多个命令同时发生，第二个命令可能会被延迟，因为ATT是一个阻塞协议。为了解决这个问题，核心5.2版本引入了扩展属性协议（Extended Attribute Protocol，EATT），允许多个ATT实例同时运行。

下图提供了一个蓝牙低功耗音频架构的概述，将所有18个构成GAF的规范以及当前顶级配置文件中的四个规范与一个名称或一组字母对应起来。虚线框表示一起工作的配置文件和服务的组合。在大多数情况下，一个配置文件和一个服务之间存在一对一的关系，但在基本音频配置文件（Basic Audio Profile，BAP）和语音控制配置文件（Voice Control Profile，VCP）的情况下，一个配置文件可以运行三个不同的服务。公共广播配置文件（Public Broadcast Profile，PBP）是一个异常情况，因为它是一个没有服务的配置。

1. 通用音频框架

1.1 BAPS-流配置和管理

从上图底部开始，我们有一组四个规范，它们被统称为BAPS规范。这四个规范构成了通用音频框架的基础。在它们的核心是BAP（基本音频配置文件），用于设置和管理单播和广播音频流。作为一个配置文件，它与三个服务一起工作：

PACS（Published Audio Capabilities Service）是发布音频能力服务，它公开了设备的能力。

ASCS（Audio Stream Control Service）是音频流控制服务，它定义了用于设置和维护单播音频流的状态机。

BASS（Broadcast Audio Scan Service）是广播音频扫描服务，它定义了发现和连接广播音频流以及分发广播加密密钥的过程。

它们负责设置承载音频数据的同步通道的基础架构。它们还定义了与LC3兼容的一组编解码器配置以及与广播和单播应用程序相应的一系列服务质量（QoS）设置。

每个单独的等时通道都定义了单播和广播状态机，两者都将音频流通过配置的状态移动到流状态，如下图中简化的状态机所示。

对于单播，状态机在ASCS规范中定义。状态位于服务器中的单个音频端点内，客户端控制由BAP定义。对于广播，由于发送器和接收器之间没有连接，客户端-服务器模型的概念变得有些模糊。因此，只有发射器定义了一个状态机，并且完全由其本地应用程序控制。对于广播，接收器需要检测流的存在并接收它，但它无法影响其状态。

多个单播或广播等时通道绑定在一起形成组。BAP定义了如何将这些组及其组成等时通道组合用于广播和单播流。

你可以使用这三个规范中的三个来制造一个蓝牙低功耗音频产品：BAP、ASCS和PACS用于单播，BAP单独用于广播（但如果你想使用电话或遥控器来帮助查找广播，你需要添加PACS和BASS）。在功能方面，这将是一个非常有限的设备 - 只是设置音频流，使用它来传输音频并停止它。然而，通过能够做到这一点，BAPS规范集为所有蓝牙低功耗音频设备提供了基本的互操作性。如果两个蓝牙低功耗音频设备具有不同的顶级配置文件，它们仍然应该能够使用BAP设置音频流。它可能具有受限制的功能，但应提供可接受的性能水平，消除了蓝牙经典音频中存在的多配置文件不兼容性问题，即没有通用音频配置文件的设备无法一起工作。

1.2 渲染和捕获控制

设置音频流后，用户希望控制音量，包括在他们耳边呈现的音频流和麦克风的拾音。

音量是一个非常困难的主题，因为音量可以在多个地方进行调整 - 在源设备上，在助听器、耳塞或扬声器上，或者在另一个“遥控器”设备上，这可能是智能手表或单独的控制器。在蓝牙低功耗音频中，最终的音量是通过助听器、耳塞或扬声器进行调节的，而不是在传入的音频流中（尽管顶级配置文件可能也需要这样做）。根据这个假设，音量控制配置文件（VCP）定义了客户端如何管理音频接收器设备的增益。该增益的状态在音量控制服务（VCS）中定义，每个音频接收器都有一个VCS实例。音量可以表示为绝对或相对值，也可以静音。

在有多个音频流的情况下，就像耳塞和助听器一样，需要第二个服务。VOCS - 音量偏移控制服务，有效地充当平衡控制器，允许调整多个设备的相对音量。这些设备可能在不同的设备上呈现，例如单独的左耳塞和右耳塞或扬声器，或者在单个设备上，如一对耳机或音响。音频输入控制服务（AICS）承认大多数设备具有支持多个不同音频流的能力，如图2.10所示。AICS提供了控制多个不同的输入的能力，这些输入可以混合在一起并在您的耳塞或扬声器中呈现。下图说明了这三个服务如何在具有蓝牙、HDMI和麦克风输入的音响中使用。

Audio Input Control Service (AICS), Volume Control Service (VCS) and Volume Offset Control Service (VOCS)。

对于一个助听器，输入可能是蓝牙流、提供环境音频流的麦克风和接收来自音频回路的流的电感天线。在任何时间点，佩戴者可能想要听到这些不同输入的组合。AICS支持这种灵活性。

音量服务的一个重要特点是，服务器的音量有变化，就会通知客户端，使其他的潜在客户端保持最新的音量相关的状态。无论是蓝牙连接还是本地音量控制，音量都是同步的。

MICP和MICS是一对补充规范，分别负责控制位于助听器和耳塞中的麦克风。如今，这些设备通常包含多个麦克风。助听器不仅监听周围环境的声音（其主要功能），还监听通过蓝牙接收的音频。随着耳塞变得越来越复杂，我们越来越多地看到类似的环境声音功能被内置其中，并且在一定程度上越来越受欢迎。

MICP与AICS和MICS协同工作，控制多个麦克风的总体增益和静音。它们通常用于控制捕获的音频，该音频旨在用于蓝牙流，但可以更广泛地使用。下图说明了它们在音响中的应用，其中麦克风输入1和2既用于环境声音又用于蓝牙流。

1.3 内容控制

在指定了如何设置和管理音频流以及如何处理音量和麦克风输入之后，我们来谈谈内容控制。我们听的内容是在蓝牙规范之外生成的 - 可能是音乐流，电视直播，电话或视频会议。

内容控制规范所做的是允许开始、停止、接听、暂停和选择音频流。这些是我们之前在HFP和Audio/Video Remote Control Profile（AVRCP）中嵌入的控制类型，该规范与A2DP一起出现。

在蓝牙LE Audio中，它们被分为两组规范 ：

• 一组用于所有形式的电话，
• 另一组用于媒体。

关键区别在于，电话通常反映电话服务的状态，而媒体控制则作用于流的状态 - 何时播放以及如何选择。

由于这些规范与音频流分离，因此现在可以用于帮助控制过渡，例如在接受电话时暂停音乐播放，当电话结束时恢复它。

对于这两组规范，服务位于主要的音频源上 - 通常是电话、PC、平板电脑或电视，而配置文件则是在接收设备上实现的，例如助听器或耳塞。

与渲染和捕获控制类似，多个设备可以充当客户端，因此可以从智能手表和耳塞控制电话和媒体状态。

媒体控制服务（MCS）位于音频媒体源上，并反映音频流的状态。状态机允许使用媒体控制配置文件（MCP）的客户端通过播放、暂停和搜索状态转换每个媒体源。在最简单的情况下，它允许耳塞控制播放和停止。然而，MCS远远超过了这一点，提供了用户今天从内容播放器期望的所有功能。它还提供了更高级别的功能，用户可以搜索音轨、修改播放顺序、设置组和调整播放速度。它定义了元数据结构，可以用来识别音轨，并使用现有的对象传输服务（OTS）来允许客户端在服务器上或更典型的是在其后面的应用程序上执行媒体搜索。所有这些意味着运行媒体控制配置文件的适当复杂的设备可以重新创建音乐播放器的控件。

电话控制是通过类似的方式使用电话承载服务（TBS）进行处理的，该服务驻留在涉及呼叫的设备上（通常是电话、PC或笔记本电脑），并由补充的呼叫控制配置文件（CCP）通过写入TBS实例中的状态机来控制呼叫。TBS和CCP已经超越了免提配置文件的限制，以适应我们现在使用多种不同形式的电话的情况。它不再只是传统的电路交换和蜂窝承载，还有PC和基于网络的通信和会议应用程序，使用多种不同类型的承载服务。TBS使用通用状态机公开呼叫的状态。它支持多个呼叫、呼叫处理和加入、来电显示以及外线和内线铃声选择，并公开了诸如信号强度之类的呼叫信息。

TBS和MCS都承认可能存在多个媒体源和服务器设备上的多个不同呼叫应用程序。为了适应这种情况，TBS和MCS都可以实例化多次 - 每个应用程序一个实例。这允许具有补充配置文件的客户端分别控制每个应用程序。或者，可以使用单个实例的服务，其中媒体或呼叫设备使用其特定的实现将配置文件命令指导到正确的应用程序。TBS和MCS的单一实例变体被称为通用电话承载服务（GTBS）和通用媒体控制服务（GMCS），并分别包含在TBS和MCS规范中。

1.4 过渡和协调控制

它们的目的是将其他规范粘合在一起，为顶级配置文件提供一种调用它们的方法，而不必关心设置细节。

Isochronous Channels的主要增强之一是能够将音频流式传输到多个不同的设备并同时呈现。这种最常见的应用是在将立体声音乐流式传输到左耳塞、右耳塞、扬声器或助听器时。呈现的拓扑和同步处理在核心和BAP中处理，但确保控制操作同时发生，无论是更改音量还是在不同连接之间进行转换，这并不在处理范围内。这就是协调集标识配置文件（CSIP）和协调集标识服务（CSIS）发挥作用的地方。

当预计使用两个或更多个蓝牙低功耗音频设备一起使用时，它们被称为协调集，可以通过使用协调集标识服务来彼此关联。这允许其他配置文件（特别是CAP）将它们视为单个实体。它引入了锁定和等级的概念，以确保在音频连接之间进行转换时，集合中的成员始终一起反应。这防止仅将新连接应用于集合中的设备子集，例如电视连接到您的右耳塞，而手机连接到您的左耳塞。旨在成为协调集成员的设备通常在制造期间配置为集合成员。

多个未配置为协调集成员的设备仍然可以在GAF中用作临时集。在这种情况下，它们需要由应用程序单独配置。这意味着它们无法从CSIS的锁定功能中受益，这可能导致与临时集成员的不同连接。

CAP（通用音频配置文件）引入了Commander角色，它将可用于远程控制蓝牙低功耗音频流的功能结合在一起。Commander是我们在前几个蓝牙规范中看到的重大变化，它提供了一种设计用于音频的无处不在的分布式远程控制的方法。对于加密广播特别有用，它提供了将广播传输转换为私人聆听体验的方式。

CAP使用CSIS和CSIP将设备连接在一起，并确保对两者都应用程序。它还引入了上下文类型和内容控制ID的概念，使应用程序能够根据控制设备、音频数据的用例以及可用的应用程序来做出有关流设置和控制的决策。这用于在不同类型的流之间进行转换，无论是由设备上的不同应用程序提示还是来自不同设备的音频连接请求。许多这种功能都基于在蓝牙低功耗音频中引入的新概念.

1.5 顶层协议

最后，在GAF规范的顶部，我们有顶级配置文件，它们为特定的音频用例提供额外的要求。其中第一个是Hearing Access Profile和服务（HAP和HAS），涵盖了助听器生态系统的应用程序；Telephony和媒体音频配置文件（TMAP），它指定了使用更高质量的编解码器设置以及更复杂的媒体和电话控制；公共广播配置文件（PBP），它帮助用户选择全球互操作的广播流。公共广播配置文件是不寻常的，因为它没有伴随的服务，但这是广播性质的后果，对于任何客户端-服务器交互都没有连接。

1.6 LC3

The Low Complexity Communications Codec (LC3)是一种用于蓝牙低功耗（Bluetooth Low Energy，BLE）的音频编解码器。它旨在提供高质量的声音传输，同时减少所需的带宽和处理能力。LC3是由蓝牙SIG（Special Interest Group）制定的规范，并已成为BLE音频传输的事实标准。LC3编解码器提供了多种设置，包括低延迟、高清晰度和高保真度选项，以满足不同应用场景的需求。它还支持多点连接和广播传输，使其在各种蓝牙设备之间的音频共享和通信中非常有用。

虽然不是GAF的一部分，但蓝牙低功耗（Bluetooth Low Energy，BLE）音频发布包括一种新的高效编解码器，称为LC3。它是蓝牙LE音频流的强制编解码器。它提供了出色的电话语音、宽带和超宽带语音以及高质量音频的性能，并在BAP中是强制使用的编解码器。每个蓝牙LE音频产品都必须支持LC3编解码器，以确保互操作性，但如果制造商需要，也可以添加额外的专有编解码器。LC3将音频编码为单个流，因此立体声被编码为单独的左和右流。这意味着GAF可以将单播流配置为仅携带耳塞所需的音频。通常，发送音乐的广播发射器在其广播中包括左右音频流。各个设备只需要接收和解码与它们想要呈现的流相关的数据即可。