第2章-Bluetooth® LE audio架构

机器翻译结果，仅用于学习，不喜勿喷，原文档链接。

蓝牙spec开发遵循一个明确定义的过程。它从新工作提案开始，该提案开发用例并评估市场对任何新功能的需求。新工作提案通常由一个小型研究小组生成，该小组由几家想要该功能的公司组成，然后由对其感兴趣的任何其他人分享和评估。届时，会询问其他蓝牙 SIG 成员是否有兴趣帮助开发和制作原型，以查看是否有足够的临界质量来实现它。

一旦证明了该级别的承诺，Bluetooth SIG 董事会将对其进行审查并将其分配给一个小组，以将初始提案转化为一组要求，并在用例上添加更多内容。审查这些要求以确保它们适合当前的蓝牙技术架构而不破坏它，然后开始开发。一旦spec被认为或多或少完整，来自多个成员公司的实施团队开发原型，这些原型在互操作性测试活动中相互测试，检查功能是否工作并满足原始要求。这也提供了一个很好的检查spec是可以理解的和明确的。任何剩余的问题都在那个阶段得到解决，一旦完成并且一切都被证明是有效的，spec就会被采用并发布。只有在那个阶段，公司才被允许生产产品、对其进行认证并开始销售。

尽管我们总是试图在这个过程中避免spec蔓延，但我们几乎总是失败，所以新特性往往会被添加到原始特性中。在LE audio 的发展过程中尤其如此，因为它已经从一个适度简单的助听器解决方案演变为目前的形式，为未来二十年的蓝牙音频产品提供工具包。为了帮助理解为什么我们最终制定了超过 20 项新spec，从最初的用例出发，了解最终架构是如何确定的，这很有用

2.1 The use cases

在LE audio 开发的最初几年，我们看到了四个主要的用例浪潮和需求推动了它的发展。它始于一组来自助听器行业的用例。这些都集中在拓扑、功耗和延迟上。

2.1.1 助听器使用案例

助听器拓扑是蓝牙经典音频profile的一大进步，因此我们将从它们开始。

2.1.1.1 基本电话

图 2.1。显示了助听器的两个电话用例，允许助听器连接到电话。这是一项重要要求，因为将手机放在耳边的助听器旁边通常会造成干扰。

左边最简单的拓扑是从电话到助听器的音频流，它允许返回流，主要针对电话。它可以配置为使用助听器上的麦克风来捕捉回声，或者用户可以对着手机说话。这与Hands-Free profile (HFP) 所做的没有什么不同。但从一开始，助听器需求就有了音频流的两个方向是独立的，可以由应用程序配置的概念。换句话说，从电话到助听器的流，以及从助听器到电话的返回流将分别配置和控制，以便可以打开或关闭。图 2.1 右侧的拓扑超出了 A2DP 或 HFP 所能做的任何事情。在这里，电话向左右助听器发送单独的左右音频流，然后增加来自每个助听器麦克风的可选返回流的复杂性。这引入了蓝牙经典音频profile可以管理的任何内容之外的第二步，需要将单独的等时流传输到两个独立的音频设备。

2.1.1.2 来自电视的低延迟音频

该要求的一个有趣扩展源于助听器可以继续接收环境声音以及蓝牙音频流这一事实。许多助听器不会堵住耳朵（堵住是行业术语，用于堵住耳朵，就像耳塞一样），这意味着佩戴者总是听到混合的环境声和放大的声音。由于助听器内的处理延迟非常小——不到几毫秒，这不存在问题。然而，在类似图 2.2 的情况下，它成为一个问题，其中一些佩戴者的家人正在通过电视的扬声器收听声音，而助听器用户听到来自电视的环境声音以及相同音频的混合通过他们的蓝牙连接流式传输。

如果两个音频信号之间的延迟远远超过 30 – 40 毫秒，它就会开始添加回声，使声音更难以解释，这与助听器应该做的相反。 30 – 40 毫秒的延迟比大多数现有 A2DP 解决方案所能提供的延迟要短得多，因此这引入了非常低延迟的新要求。

虽然助听器的带宽要求相对适中，单声道语音的带宽为 7kHz，立体声音乐的带宽为 11kHz，但现有的蓝牙编解码器在满足延迟要求的同时无法轻松满足这些要求。这导致了对合适编解码器的性能要求范围的单独调查，从而引入了 LC3 编解码器，我们将在第 5 章中介绍。

2.1.1.3 添加更多用户

听力损失可能在家庭中发生，并且通常与年龄有关，因此家庭中通常有不止一个人佩戴助听器。因此，新的拓扑结构需要支持多个助听器佩戴者。图 2.3 说明了两个人的用例，他们都应该经历相同的延迟。

2.1.1.4 增加更多的监听器以支持更大的区域

拓扑结构还应该是可扩展的，以便多人可以听，就像在教室或疗养院一样。该要求依赖于一个频谱，该频谱延伸到为当前的感应线圈提供广播替代品。这需要一个蓝牙广播发射器，它可以广播单声道或立体声音频流，能够被范围内的任意数量的助听器接收，如图 2.4 所示。

图 2.4 还认识到，有些人只有一只耳朵有听力损失，而另一些人两只耳朵都有听力损失（这通常可能是不同程度的听力损失）。这意味着应该可以在广播单声道信号的同时广播立体声信号。它还强调了这样一个事实，即用户可能会佩戴来自两家不同公司的助听器来应对这些差异，或者一只耳朵戴助听器，另一只耳朵戴消费者耳塞。

2.1.1.5 协调左右助听器

无论组合如何，都应该可以将一对助听器视为一组设备，以便它们都连接到相同的音频源，并且音量控制等共同功能以一致的方式在它们上工作。这引入了协调的概念，可能来自不同制造商的不同设备将同时接受控制命令并以相同的方式解释它们。

2.1.1.6 帮助查找广播和加密

使用 Telecoil，用户只有一个选择来获取信号——打开他们的 Telecoil 接收器，它从围绕他们的感应回路中拾取音频，或者将其关闭。一个区域中只能存在一个感应线圈信号，因此您不必选择所需的信号。另一方面，这意味着你不能同时广播多种语言。

借助蓝牙，多个广播发射器可以在同一区域内运行。这具有明显的优势，但引入了两个新问题——如何获取正确的音频流，以及如何防止其他人听到私人对话？

为了帮助选择正确的流，重要的是用户可以找到关于他们是什么的信息，这样他们就可以直接跳到他们的首选。这种体验的丰富程度显然会有所不同，具体取决于在助听器、电话或远程遥控上搜索广播流的方式，但spec需要涵盖所有这些可能性。许多公共广播不需要是私人的，因为它们会加强公共音频公告，但其他一些则需要。在像家里这样的环境中，您不会想拿起邻居的电视。因此，可以对音频流进行加密非常重要，需要能够将加密密钥分发给授权用户。这个过程必须是安全的，但很容易做到。

除了低延迟之外，模拟当前助听器的使用还增加了一些其他限制。在用户佩戴两个助听器的情况下，无论是接收相同的单声道还是立体声音频流，都需要在 25µs 内渲染音频，以确保音频图像保持稳定。对于立体声耳塞来说同样如此，但当左右设备可能来自不同的制造商时，这是一个挑战。

2.1.1.7 实际要求

助听器非常小，这意味着它们的按钮空间非常有限。所有年龄段的人都可以佩戴它们，但一些年长的佩戴者的手动灵活性有限，因此调节音量和建立连接的控件可以在其他更易于使用的设备上实现，这一点很重要。这可能是音频源，通常是用户的电话，但助听器用户通常也有像远程遥控这样的小钥匙扣。

这些具有立即工作的优点。如果您想降低助听器的音量，只需按下音量或静音按钮即可；您无需启用手机、找到助听器应用程序并从那里控制它。这可能需要很长时间，而且不是大多数助听器用户喜欢的用户体验。他们需要一种快速方便的音量和静音控制方法，否则他们会将助听器从耳朵中取出，这是不希望的行为。

助听器对音量还有一个要求，就是在助听器上实现音量级（实际上是增益）。这样做的理由是，如果音频流在线路级别 2 传输，您将获得最大的动态范围。对于处理声音的助听器，输入信号提供最佳的信噪比非常重要，尤其是当它与来自环境麦克风的音频流混合时。如果在源处降低音频增益，则会导致较低的信噪比。

助听器与耳塞或耳机之间的一个重要区别在于，助听器大部分时间都在佩戴，并且不断处于活动状态，放大和调整环境声音以帮助佩戴者听得更清楚。用户不会定期将它们取下并放回充电盒中。每天佩戴一副助听器的典型时间约为九个半小时，尽管有些用户可能会佩戴十五小时或更长时间。这与耳塞和耳机非常不同，耳塞和耳机仅在用户即将拨打或接听电话或收听音频时佩戴。耳塞制造商在充电盒的设计上非常聪明，鼓励用户在一天中定期为耳塞充电，给人一种电池寿命更长的印象。助听器没有这种选择，因此设计人员需要尽其所能将功耗降至最低。

耗电的事情之一是寻找其他设备并保持后台连接。耳塞会收到关于何时执行此操作的明确信号——即当它们从充电盒中取出时。大多数还包含光学传感器，以检测它们何时在耳朵中，因此如果它们在您的办公桌上，它们可以重新入睡。助听器不会获得相同的、明确的信号来启动蓝牙连接，因为它们始终处于开启状态，并且始终充当助听器。这意味着他们需要在等待某些事情发生时与其他设备保持持续的蓝牙连接。这些可以是低占空比连接，但不能太低，否则助听器可能会错过来电，或者需要很长时间才能响应正在启动的音乐流媒体应用程序。因为助听器可能连接到多个不同的设备，例如电视、电话，甚至是门铃，这样的连接会消耗过多的电量，因此需要一种新的机制来允许它们与一系列不同的产品，而不会影响电池寿命。

2.1.2 支持助听器用例的核心要求

定义了拓扑和连接的要求后，很明显需要将大量新功能添加到核心spec中以支持它们。这导致了第二轮工作，以确定如何最好地满足 Core 中的助听器要求。

该过程的第一部分是分析是否可以通过扩展现有的蓝牙音频spec而不是在蓝牙低功耗中引入新的音频流功能来支持新功能。如果可能的话，它将提供与当前音频profile的向后兼容性。结论与最初开发低功耗蓝牙时进行的分析类似，即它会涉及太多妥协，最好在 Core 4.1 低功耗spec之上进行“干净的表”设计。

Core 的提议是实现一个名为 Isochronous Channels 的新功能，它可以在BLE 中传输音频流，以及现有的 ACL通道。 ACL 通道将用于配置、设置和控制流，以及携带更通用的控制信息，例如音量、电话和媒体控制。同步通道可以支持单向或双向音频流，并且可以为多个设备设置多个同步通道。这将音频数据和控制平面分开，这使得LE audio 更加灵活。

音频连接的稳健性很重要，这意味着它们需要支持多次重传，以应对某些传输可能受到干扰的事实。对于单播流，有一个 ACK/NACK 确认方案，因此一旦发送器知道已接收到数据，就可以停止重传。对于没有反馈的广播，源需要无条件地重新传输音频数据包。在研究鲁棒性的过程中，很明显用于保护 LE 设备免受干扰的跳频方案可以改进，因此将其作为另一项要求添加。

广播需要一些新概念，特别是在设备如何在没有连接的情况下找到广播方面。低功耗蓝牙使用Advertising让设备宣布它们的存在。想要对这些Advertising进行连接扫描的设备，然后连接到他们发现的设备，以获取它支持什么、如何连接的详细信息——包括关于它何时传输、它的跳跃序列是什么以及它做什么的信息。根据LE audio 的要求，这需要比普通BLE Advertising更多的信息。为了克服这一限制，Core 添加了Extended Adv (EA) 和 Periodic Advertising train (PA) 的新功能，允许在通常不用于Advertising的一般数据通道上的数据包中携带此信息。为此，它为接收设备添加了新程序，以使用此信息来确定广播音频流的位置并与之同步。

外部设备可以帮助找到广播流的要求增加了一个要求，即它可以通知接收器如何连接到该流 - 本质上是接收器从远程遥控询问方向并被告知去哪里的能力.这是通过称为 PAST（Periodic Advertising同步传输）的核心功能实现的，这是使广播获取变得简单的关键。 PAST 对助听器来说是一个非常有用的功能，因为扫描需要很大的功率。最小化扫描是一个有用的功能，有助于延长助听器的电池寿命。

助听器要求还导致核心要求中添加了一些其他功能，主要是围绕性能和节能。第一个是在host或controller中实现新编解码器的能力。后者使硬件实现更容易，通常更节能。第二个是对传输或接收需要持续的最长时间进行限制，这会影响同步Channel中数据包结构的设计。这背后的原因是，许多助听器使用一次锌空气电池，因为它们的功率密度很高。然而，这种电池化学成分依赖于限制电流尖峰和高功率电流消耗。不遵守这些限制会导致电池寿命显着缩短。与他们的相遇塑造了等时通道的整体设计。

核心要求的最后两个补充是在开发过程中比较晚才出现的，它们是同步适应层 (ISOAL) 和增强属性协议 (EATT) 的引入。

ISOAL 允许设备在链路层将服务数据单元 (SDU) 从上层转换为不同大小的协议数据单元 (PDU)，反之亦然。需要这样做的原因是为了应对可能使用新 LC3 编解码器的推荐时序设置的设备，该编解码器针对 10 毫秒帧进行了优化，以及与以 7.5 毫秒时序间隔运行的旧蓝牙设备的连接。

EATT 是对BLE 的标准属性协议 (ATT) 的增强，以允许 ATT 协议的多个实例同时运行。

Core 5.1 版本采用了Extended Adv功能，在最近的 Core 5.2 版本中采用了同步通道、EATT 和 ISOAL，为在它们之上构建所有其他LE audio spec铺平了道路。

2.1.3 做HFP和A2DP能做的一切

随着消费电子行业开始认识到LE audio 功能的潜力，这些功能解决了他们多年来发现的许多问题，他们提出了第三轮要求的务实要求，以确保LE audio 能够能够做 A2DP 和 HFP 可以做的所有事情。他们指出，如果用户体验更差，没有人愿意使用LE audio 而不是蓝牙经典音频。

这些要求提高了对新编解码器的性能要求，并为媒体和电话控制引入了一组更为复杂的要求。最初的助听器要求包括与手机交互的非常有限的控制功能，假设大多数用户将直接控制手机或电视上更复杂的功能，尤其是因为助听器的用户界面如此有限。许多消费类音频产品更大，因此没有这个限制。因此，增加了新的电话和媒体控制要求，以实现更复杂的控制。

2.1.4 超越 HFP 和 A2DP

第四轮要求反映了音频和电话应用已经超过了 HFP 和 A2DP。当今的许多呼叫都是 VoIP，并且多个不同的呼叫到达单个设备是很常见的——无论是笔记本电脑、平板电脑还是手机。蓝牙技术需要一种更好的方式来处理来自多个不同承载的呼叫。同样，A2DP 没有预料到流媒体以及随之而来的搜索要求，因为它是在用户拥有本地音乐副本并且很少做比选择本地文件更复杂的事情时编写的。今天，产品需要更复杂的媒体控制。他们还需要能够在不中断音乐流的情况下支持语音命令。

当今的电话和会议应用程序中用户处理多种类型的呼叫以及音频流的复杂性意味着他们在设备和应用程序之间进行更频繁的转换。 HFP 和 A2DP 之间在架构上的内在差异总是让这变得困难，因此产生了一组最佳实践规则，这些规则构成了 HFP 和 A2DP 的多profilespec。新的LE audio 架构将不得不超越这一点，并通过设计整合多profile支持，在设备和应用程序之间以及单播和广播之间实现强大且可互操作的转换。

随着消费者领域越来越多的人开始了解助听器的感应线圈和广播功能的工作原理，他们开始意识到广播可能有一些非常有趣的大众消费应用。他们的首要任务是意识到它可以用于分享音乐。这可能是朋友分享手机中的音乐、无声的迪斯科舞厅或咖啡店和公共场所的“无声”背景音乐。公共广播装置，例如那些旨在为助听器佩戴者提供旅行信息的装置，现在每个人都可以使用蓝牙耳机访问。我们将在第 12 章详细讨论的音频共享的概念诞生了。

潜在的新用例开始激增。如果我们可以同步两个耳塞的立体声通道，为什么不能为环绕声呢？公司热衷于确保它支持智能手表和腕带，它们可以充当远程遥控，甚至是带有嵌入式 MP3 播放器的音频源。低延迟对游戏社区来说是令人兴奋的。微波炉可以告诉您晚餐何时煮熟（您可以看出这个想法来自工程师）。随着公司看到它如何使他们的客户、他们的产品策略受益并影响语音和音乐的未来使用，用例的数量继续增长。

功能的数量意味着完成spec需要很长时间。令人欣慰的是，过去几年提出的大多数新用例都不需要我们返回并重新打开spec——我们发现它们已经得到了已经定义的特性的支持。这表明LE audio 标准经过精心设计，能够支持我们今天拥有的音频应用程序以及即将到来的新音频应用程序。

2.2 BLE音频架构

与之前的所有其他蓝牙spec一样，LE audio 架构是分层构建的。这在图 2.5 中进行了说明，它显示了与LE audio 相关的主要新spec块（现有的关键部分以灰色或虚线显示）。

在底部，我们有核心，它包含无线电和链路层（统称为controller）。它负责无线发送蓝牙数据包。最重要的是host，它的任务是告诉核心为任何特定的应用程序做什么。controller和host之间的分离是历史性的，反映了蓝牙无线电以 USB 记忆棒或 PCMCIA 卡形式出售的日子，host作为 PC 上的软件应用程序实现。今天，host和controller通常都集成到一个芯片中。

在host中，有一个称为通用音频框架或 GAF 的新结构。这是一个音频中间件，它包含所有被认为是通用的功能，即可能被多个音频应用程序使用的功能。 Core 和 GAF 是LE audio 的核心。它们提供了极大的灵活性。最后，在堆栈的顶部，我们有所谓的“顶层”profile，它将应用程序特定信息添加到 GAF spec中。

完全有可能仅使用 GAF spec来构建可互操作的LE audio 应用程序。其中的各个spec已被定义为确保基本级别的互操作性，这将使任何两个LE audio 设备能够在它们之间传输音频。上层profilespec主要添加特定于特定类型的音频应用程序的功能，强制 GAF 仅定义为可选的功能，并添加特定于应用程序的功能。目的是顶层profile相对简单，建立在 GAF 内的功能之上。

乍一看，LE audio 架构看起来很复杂，因为我们最终在通用音频框架内拥有 23 种不同的spec，以及扩展的核心和新的 LC3 编解码器。但这是有逻辑的。每个spec都试图封装您设置和控制音频流不同方面的方式的特定元素。在本章的其余部分，我将简要解释每一个以及它们如何组合在一起。然后，在本书的其余部分，我们将研究每个单独的spec是如何工作的以及它们是如何相互作用的。

2.2.1 Profile和服务

GAF 中的所有spec都使用图 2.6 中描述的标准BLE GATT 模型归类为profile或服务。

在低功耗蓝牙中，profile和服务可以被视为client和server。 Service 在 state所在的地方实现，而 Profile spec描述了 state 的行为方式并包括管理它的过程。服务spec定义了一个或多个特性，这些特性可以表示单个特性或状态机的状态。它们也可以是控制点，导致状态机状态之间的转换。profile作用于这些特征，读取或写入它们，并在值更改时收到通知。多个设备，每个都充当client，可以在server上运行。

传统上，在经典的蓝牙profile（没有相应的服务）中，只有一个client和一个server存在简单的一对一关系，所有内容都在profilespec中描述。在LE audio 中，多对一拓扑更为常见，特别是在音量控制和广播源选择等功能中，用户可能有多个设备实现 Profile spec并充当client。在大多数情况下，这些都是先到先得的原则。

可在LE audio 中使用的不同控制profile的数量推动了核心的 EATT 增强。profile和服务使用属性协议 (ATT) 进行通信，但 ATT 假定一次只发生一个命令。如果不止一个发生，第二个命令可以延迟，因为 ATT 是一个阻塞协议。为了解决这个问题，Core 5.2 版本中添加了扩展属性协议 (EATT)，允许多个 ATT 实例同时运行。

图 2.7 提供了LE audio 架构的概述，为构成 GAF 的所有 18 个spec以及当前上层profile中的四个spec命名，或更准确地说，是一组字母。虚线框表示协同工作的profile和服务集。在大多数情况下，profile和服务是一对一的关系，尽管在基本音频profile (BAP)和语音控制profile (VCP) 的情况下，一个profile可以在三种不同的服务上运行。公共广播profile (PBP) 是一个异常，因为它是一个没有服务的profile，但这是广播的后果之一，因为当没有连接时，您无法进行传统的client-server交互。

2.2.2 通用音频框架

我们现在可以看看 GAF 的组成部分。各种spec之间存在大量交互，因此很难在它们之间绘制清晰的层次结构或关系集，但它们可以大致分为四个功能组，如图 2.8 所示。

这种分组主要是为了解释。在LE audio 的实际实现中，这些spec中的大多数都或多或少地相互影响。完全有可能只用其中的几个来制作工作产品，但要设计功能丰富、可互操作的产品，则需要其中的大部分。

2.2.3 流配置和管理——BAPS

从图 2.8 的底部开始，我们有一组四个spec，它们统称为 BAPS spec。这四个spec构成了通用音频框架的基础。它们的核心是 BAP——基本音频profile，用于设置和管理单播和广播音频流。作为profile，它适用于三种服务：

• PACS – 发布的音频功能服务，它公开设备的功能，
• ASCS - 音频流控制服务，它定义了用于设置和维护单播音频流的状态机，以及
• BASS - 广播音频扫描服务，它定义了发现和连接到广播音频流以及分发广播加密密钥的过程。

在它们之间，它们负责我们设置承载音频数据的底层同步通道的方式。它们还为 LC3 定义了一组标准的编解码器配置，以及用于广播和单播应用程序的相应服务质量 (QoS) 设置范围。

每个单独的同步通道的状态机都为单播和广播定义，两者都将音频流从配置状态移动到流状态，如图 2.9 的简化状态机所示。

对于单播，状态机在 ASCS spec中定义。状态驻留在server中的各个音频endpoint 中，client控件在 BAP 中定义。对于广播，发送器和接收器之间没有连接，client-server模型的概念变得有点脆弱。因此，状态机仅为发送器定义，并且完全受其本地应用程序的控制。使用广播，接收者需要检测流的存在然后接收它，但无法影响其状态。

多个单播或广播同步频道以组的形式绑定在一起（我们将在第 4 章中探讨）。 BAP 定义了如何将这些组及其组成的同步通道放在一起以用于广播和单播流。

您可以只使用其中三个规格来制作LE audio 产品； BAP、ASCS 和 PACS 用于单播，BAP 单独用于广播（但如果您想使用电话或远程遥控帮助查找广播，则需要添加 PACS 和 BASS）。就功能而言，这将是一个非常有限的设备——只需设置一个音频流，使用它来传输音频并停止它。但是，由于能够做到这一点，BAPS spec集为所有LE audio 设备提供了基本级别的互操作性。如果两个LE audio 设备具有不同的上层profile，它们应该仍然能够使用 BAP 设置音频流。它可能功能受限，但应提供可接受的性能水平，消除蓝牙经典音频中存在的多profile不兼容问题，即没有通用音频profile的设备无法协同工作。

2.2.4 Rendering and capture control

设置流后，用户想要控制音量，既要在他们的耳朵中呈现音频流，又要控制麦克风的拾音。

音量是一个非常困难的话题，因为可以在多个地方调节音量——在源设备上、在助听器、耳塞或扬声器上，或者在另一个“远程控制”设备上，这可能是智能手表或单独的controller。在LE audio 中，音量的最终增益在助听器、耳塞或扬声器中执行，而不是在传入的音频流上执行（尽管上层profile可能也需要这样做）。有了这个假设，音量控制profile (VCP) 定义了client如何管理音频接收器设备上的增益。该增益的状态在音量控制服务 (VCS) 中定义，每个音频接收器上都有一个 VCS 实例。音量可以表示为绝对或相对，也可以静音。

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

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

音量服务的一个重要特性是它们会将任何更改通知回运行语音控制profile的client设备。这可确保所有潜在的controller都及时了解其状态的任何变化，无论是通过蓝牙链接还是通过本地音量控制发生的。这确保了他们都拥有音量状态的同步知识，以便用户可以从其中任何一个进行更改，而不会因他们对音量级别的当前状态的过时了解而产生任何意外影响。

一对互补的spec，MICP 和 MICS，即麦克风控制profile和服务，负责控制驻留在助听器和耳塞中的麦克风。如今，这些设备通常包含多个麦克风。助听器既可以收听环境声音（它们的主要功能），也可以收听通过蓝牙接收的音频。随着耳塞变得越来越复杂，我们越来越多地看到它们内置了类似的环境声音功能，并且由于某种程度的透明度而越来越受欢迎。

MICP 与 AICS 和 MICS 一起工作，以控制多个麦克风的整体增益和静音。它们通常用于控制以蓝牙流为目的地的捕获音频，但可以更广泛地使用。图 2.11 说明了它们的使用。

2.2.5 内容控制

在指定了流的设置和管理方式以及音量和麦克风输入的处理方式之后，我们开始进行内容控制。我们收听的内容是在蓝牙spec之外生成的——它可能是流媒体音乐、直播电视、电话或视频会议。内容控制spec所做的是允许在开始、停止、应答、暂停和选择流方面进行控制。这些是嵌入到 HFP 和 A2DP 随附的音频/视频远程控制profile (AVRCP) 中的控制类型。在LE audio 中，它们分为两组spec——一组用于所有形式的电话，另一组用于媒体。关键的区别在于电话是关于一个或多个呼叫的状态，它通常反映电话服务的状态，而媒体控制作用于流的状态——播放的时间和方式以及选择的方式。由于这些与音频流分离，它们现在可用于帮助控制过渡，例如在您接听电话时暂停音乐播放并在通话结束时恢复音乐播放。对于这两对spec，服务驻留在主要音频源上——通常是电话、PC、平板电脑或电视，而profile是在接收设备上实现的，例如助听器或耳塞。与渲染和捕获控件一样，多个设备可以充当client，因此可以通过智能手表和耳塞控制电话和媒体状态。

媒体控制服务 (MCS) 驻留在音频媒体源上并反映音频流的状态。状态机允许使用媒体控制profile (MCP) 的client通过播放、暂停和搜索状态转换每个媒体源。最简单的是，它允许耳塞控制播放和停止。然而，MCS 远不止于此，它提供了当今用户期望内容播放器提供的所有功能。它还提供更高级别的功能，用户可以搜索曲目、修改播放顺序、设置组和调整播放速度。它定义了可用于识别轨道的metadata结构，并使用现有的对象传输服务 (OTS) 来允许client在server上执行媒体搜索，或者更典型地是在其背后的应用程序上执行媒体搜索。所有这一切意味着运行媒体控制profile的适当复杂的设备可以重新创建音乐播放器的控制。

使用电话承载服务 (TBS) 以类似的方式处理电话控制，该服务驻留在参与呼叫的设备（通常是电话、PC 或笔记本电脑）上，互补的呼叫控制profile (CCP) 通过写入来控制呼叫到 TBS 实例中的状态机。 TBS 和 CCP 已经超越了Hands-Free profile的限制，以适应我们现在以多种不同形式使用电话的事实。它不再只是传统的电路交换和蜂窝承载，而是使用多种不同类型的承载服务的 PC 和基于 Web 的通信和会议应用程序。 TBS 使用通用状态机公开调用的状态。它支持多个呼叫、呼叫处理和加入、来电显示、带内和带外铃声选择，并公开呼叫信息，例如信号强度。

TBS 和 MCS 都承认server设备上可能有多个媒体源和多个不同的呼叫应用程序这一事实。为了适应这一点，两者都可以被实例化多次——每个应用程序实例一次。这允许具有补充profile的client分别控制每个应用程序。或者，可以使用服务的单个实例，其中媒体或呼叫设备使用其特定实现将profile命令定向到正确的应用程序。 TBS 和 MCS 的单实例变体称为通用电话承载服务 (GTBS) 和通用媒体控制服务 (GMCS)，分别包含在 TBS 和 MCS spec中。我们将在第 9 章中更详细地讨论这些内容。

2.2.6 Transition and coordination control

接下来，我们来看看Transition和Coordination控制spec。它们的目的是将其他spec粘合在一起，为上层profile提供一种调用它们的方法，而不必担心设置的细节。

Isochronous Channels 的主要增强功能之一是能够将音频流式传输到多个不同的设备并同时进行渲染。最常见的应用是将立体声音乐流式传输到左右耳塞、扬声器或助听器。渲染的拓扑和同步在 Core 和 BAP 中处理，但确保控制操作一起发生，无论是改变音量还是连接之间的转换都不是。这就是协调集标识profile (CSIP) 和协调集标识服务 (CSIS) 的用武之地。

如果两个或多个LE audio 设备预计一起使用，它们被称为协调集，并且可以通过使用协调集标识服务相互关联。这允许其他profile，特别是 CAP，将它们视为单个实体。它引入了 Lock 和 Rank 的概念，以确保当音频连接之间发生转换时，无论是新的单播还是广播流，集合的成员总是一起做出反应。这可以防止新连接仅应用于集合中的一部分设备，例如连接到右耳塞的电视，而手机连接到左耳塞。设计为协调集成员的设备通常在制造过程中被配置为集成员。

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

CAP——通用音频profile，引入了commander角色，它汇集了可用于远程控制LE audio 流的功能。 Commander 与我们在之前的蓝牙spec中看到的任何内容相比都发生了重大变化，允许设计无处不在的分布式音频远程控制。它对于加密广播特别有用，它提供了一种将广播传输转换为私人收听体验的方法。我们将在第 8 章中更详细地探讨这一点。

CAP 使用 CSIS 和 CSIP 将设备连接在一起，并确保将程序应用于两者。它还介绍了Context类型和内容控制 ID 的概念，它们允许应用程序根据控制设备的知识、音频数据的用例以及哪些应用程序可用来做出有关流设置和控制的决策。这用于通知不同流之间的转换，无论是由设备上的不同应用程序提示还是来自不同设备的音频连接请求。许多此类功能都基于已在低功耗蓝牙音频中引入的新概念。这些在第 3 章中有更详细的解释。

2.2.7 上层profile

最后，除了 GAF spec之外，我们还有上层profile，它们为特定音频用例提供了额外的要求。其中第一个是听力访问profile和服务（HAP 和 HAS），涵盖助听器生态系统的应用；电话和媒体音频profile (TMAP)，它指定使用更高质量的编解码器设置和更复杂的媒体和电话控制，以及公共广播profile (PBP)，它帮助用户选择全球可互操作的广播流。公共广播profile在没有伴随服务方面是异常的，但这是广播性质的结果，其中没有任何client-server交互的连接。

2.2.8 低复杂度通信编解码器（LC3）

虽然不是 GAF 的一部分，但LE audio 版本包括一个新的、高效的编解码器，称为 LC3，它是LE audio 流的强制编解码器。这为电话语音、宽带和超宽带语音以及高质量音频提供了出色的性能，并且是 BAP 中的强制编解码器。每个LE audio 产品都必须支持 LC3 编解码器以确保互操作性，但如果制造商需要，可以添加额外的专有编解码器。 LC3 将音频编码为单个流，因此立体声被编码为单独的左右流。这意味着 GAF 可以将单播流配置到耳塞，以仅传输该耳塞所需的音频。发送音乐的广播发射机通常会在其广播中同时包含左右音频流。单个设备只需要接收和解码与他们想要呈现的流相关的数据。

2.3 谈谈BLE音频

编写超过 20 个spec已经产生了许多新的缩写，包括每个单独spec的名称。随着时间的推移，工作组提出了不同的引用方式——有时是首字母缩略词（你将它们发音为单词），有时是首字母缩写词（你只是发音字母，有时是两者的混合。以下表捕获最常用的当前发音，以帮助任何谈论LE audio 的人。

2.3.1 Acronyms

以下缩写均以单词或字母和单词的组合发音：

Abbreviation	Meaning	Pronunciation
AICS	Audio Input Control Service	aches (as in aches and pains)
ASE	Audio Stream Endpoint	ase (rhymes with case)
ATT	Attribute Protocol	at
BAP	Basic Audio Profile	bap (rhymes with tap)
BAPS	The set of BAP, ASCS, BASS and PACS	baps
BASE	Broadcast Audio Source Endpoint	base (rhymes with case)
BASS	Broadcast Audio Scan Service	rhymes with mass, not mace
BIG	Broadcast Isochronous Group	big
BIS	Broadcast Isochronous Stream	biss
CAP	Common Audio Profile	cap (rhymes with tap)
CAS	Common Audio Service	cas (rhymes with mass)
CIG	Connected Isochronous Group	sig
CIS	Connected Isochronous Stream	sis
CSIP	Coordinated Set Identification Profile	see - sip
CSIS	Coordinated Set Identification Service	see - sis
CSIPS	The set of CSIP and CSIS	see - sips
EATT	Enhanced ATT	ee - at
GAF	Generic Audio Framework	gaffe
GAP	Generic Access Profile	gap (rhymes with tap)
GATT	Generic Attribute Profile	gat (rhymes with cat)
HAP	Hearing Access Profile	hap (rhymes with tap)
HARC	Hearing Aid Remote Controller	hark
HAS	Hearing Access Service	hass (rhymes with mass)
HAUC	Hearing Aid Unicast Client	hawk
INAP	Immediate Need for Audio related Peripheral	eye - nap
L2CAP	Logical Link Control and Adaptation protocol	el - two - cap
MICP	Microphone Control Profile	mick - pee
MICS	Microphone Control Service	mick - ess
PAC	Published Audio Capabilities	pack
PACS	Published Audio Capabilities Service	packs
PAST	Periodic Advertising Sync Transfer	past (rhymes with mast)
PBAS	Public Broadcast Audio Stream Announcement	pee - bass (bass rhymes with mass)
PHY	physical layer	fy (rhymes with fly)
QoS	Quality of Service	kwos
RAP	Ready for Audio related Peripheral	rap
SIRK	Set Identity Resolving Key	sirk (like the first syllable of circus)
TMAP	Telephony and Media Audio Profile	tee - map
TMAS	Telephony and Media Audio Service	tee - mas
VOCS	Volume Offset Control Service	vocks

Table 2.1 Pronunciation guide for Bluetooth® LE Audio acronyms

2.3.2 Initialisms

其余的只是简单地发音为组成缩写的单个字母，例如，CCP 发音为“see-see-pee”，LC3 发音为“el-see-three”。

LE audio 中最常见的缩写是：ACL、AD、ASCS、BMR、BMS、BR/EDR、CCID、CCP、CG、CSS、CT、CTKD、EA、FT、GMCS、GSS、GTBS、HA、HCI、 IA，IAC，IAS，INAP，IRC，IRK，LC3，MCP，MCS，MTU，NSE，PA，PBA，PBK，PBP，PBS，PDU，PTO，RFU，RTN，SDP，SDU，TBS，UI，UMR， UMS、UUID、VCP 和 VCS。这些都在词汇表中解释。

2.3.3 不规则发音

OOB 是一个奇怪的词，因为它总是被完整地说出来，即“out of band”，虽然是缩写，但通常会用在文本中。

-oOo-

那是通过通用音频框架的主要部分的一次哨声之旅。我们将在未来看到更多的spec出现在 GAF 中，但就目前而言，上述spec模拟并扩展了蓝牙今天具有的经典音频profile的音频功能。
在本书的其余部分，我们将了解 BAPS（BAP、BASS、ASCS 和 PACS）如何构成您使用LE audio 所做的一切的核心。其他spec增加了Availability和功能，而 CAP 将它们粘合在一起。作为第一步，我们将了解一些解决LE audio 要求所必需的新概念。