当前位置：首页 > news >正文

LE AUDIO---Chapter 2. The Bluetooth® LE Audio architecture

news 2025/6/26 10:59:25

2.1 The use cases

2.1.1 Hearing aid requirements - the use cases

2.1.1.1 Basic telephony

2.1.1.2 Low latency audio from a TV

2.1.1.3 Adding more users

2.1.1.4 Adding more listeners to support larger areas

2.1.1.5 Coordinating left and right hearing aids

2.1.1.6 Help with finding broadcasts and encryption

2.1.1.7 Practical requirements

2.1.2 Doing everything that HFP and A2DP can do

2.1.3 Evolving beyond HFP and A2DP

2.1.4 Addressing future audio applications

2.1.5 Core requirements to support the hearing aid use cases

2.2 The Bluetooth LE Audio architecture

2.2.1 Profiles and Services

2.2.2 The Generic Audio Framework

2.2.3 Stream configuration and management – BAPS

2.2.4 Rendering and capture control

2.2.5 Content control

2.2.6 Transition and coordination control

2.2.7 Top level Profiles

2.2.8 The Low Complexity Communications Codec (LC3)

2.3 Talking about Bluetooth LE Audio

2.3.1 Acronyms

2.3.2 Initialisms

2.3.3 Irregular pronunciations

蓝牙规范的开发遵循着一套明确的流程。其始于一项新工作提案，该提案会梳理用例并评估任何新功能的市场需求。新工作提案通常由一个小型研究小组制定，小组成员由几家期望该功能的公司组成，之后提案会被分享给其他感兴趣的各方进行评估。在这一阶段，蓝牙技术联盟（Bluetooth SIG）会询问其他成员是否有兴趣协助开发该功能并制作原型，以此判断是否有足够的支持力度推动其实现。

一旦展示出这种程度的承诺，蓝牙技术联盟（Bluetooth SIG）董事会会对其进行审查，并将其分配给一个小组，以将初始提案转化为一系列需求，并进一步充实用例内容。这些需求会经过审核，以确保它们在不破坏现有蓝牙技术架构的前提下融入其中，随后便开启开发工作。当规范基本完成后，多家成员公司的实施团队会开发原型，并在互操作性测试活动中相互测试，以检验这些功能是否有效且符合最初的需求。这也能很好地检验规范是否清晰易懂、没有歧义。任何遗留问题会在该阶段得到解决，待问题解决且所有功能验证通过后，规范便会被采纳并发布。只有到了这一阶段，各公司才被允许生产产品、进行认证并开始销售。

尽管我们在这个过程中始终试图避免规范膨胀，但几乎总是失败，因此新功能往往会被添加到原有功能中。这在蓝牙LE音频的演进过程中尤为明显，它从一个用于助听器的相对简单的解决方案，发展到如今的形式，为未来二十年的蓝牙音频产品提供了工具包。为了帮助理解为何最终形成了二十多个新规范，回顾从最初用例到最终架构确定的历程会很有帮助。

2.1 The use cases

在蓝牙LE音频发展的最初几年，我们看到有四大波用例和需求推动其演进。它最初源于助听器行业的一系列用例，这些用例主要聚焦于拓扑结构、功耗和延迟。随着越来越多的公司加入，其范围不断扩大，经历了以下几个需求阶段：

 助听器需求

 实现HFP和A2DP所能完成的所有功能

 超越HFP和A2DP的演进

 满足未来音频应用需求

2.1.1 Hearing aid requirements - the use cases

助听器的拓扑结构相较于蓝牙经典音频配置文件有了重大进步，因此我们将从这里开始介绍。

2.1.1.1 Basic telephony

图2.1展示了助听器的两种电话通信用例，使助听器能够与手机连接。这是一项重要需求，因为将手机靠近耳朵里的助听器时，常常会造成干扰。

最左侧的简单拓扑结构是从手机到助听器的音频流，并支持返回流，主要用于电话通信。该拓扑可配置为使用助听器上的麦克风捕捉返回语音，也可让用户直接对着手机讲话，这与免提配置文件（HFP）的功能并无不同。但从一开始，助听器需求就包含音频流双向独立且可由应用程序配置的概念。换言之，从手机到助听器的流与从助听器到手机的返回流可分别配置和控制，可单独开启或关闭。图2.1右侧的拓扑结构则超越了A2DP或HFP的能力范围——手机向左右助听器分别发送独立的左右音频流，还可选择性添加来自各助听器麦克风的返回流，这带来了蓝牙经典音频配置文件无法实现的复杂性，需要向两个独立音频设备发送单独的同步流。

2.1.1.2 Low latency audio from a TV

这一需求的一个有趣延伸源于以下事实：助听器可能会继续接收环境声音以及蓝牙音频流。许多助听器不会堵塞耳朵（“堵塞”是行业术语，指像耳塞一样堵住耳朵），这意味着佩戴者总是听到环境声音和放大声音的混合。由于助听器内环境声音的处理延迟极小——不到几毫秒，这不会造成问题。然而，在图2.2所示的情况下就会成为问题：部分家庭成员通过电视扬声器收听声音，而助听器使用者则既听到来自电视的环境声音，又通过蓝牙连接听到相同的音频流。

如果两个音频信号之间的延迟远超过30-40毫秒，就会开始被感知为回声，使声音更难理解，这与助听器的设计初衷相悖。30-40毫秒的延迟比大多数现有A2DP解决方案所能提供的延迟要严格得多，因此这引入了对极低延迟的新要求。环境声音30-40毫秒的延迟相当于声音传播约10米的时间，这意味着在大多数家庭房间中这不是问题。此外，该延迟也完全在大脑处理唇音同步的能力范围内，因此无需电视调整视频渲染延迟，视频和音频也会显得同步。

尽管助听器的带宽要求相对适中——单声道语音需7kHz带宽，立体声音乐需11kHz带宽，但现有蓝牙编解码器在满足该延迟要求的同时，难以轻松满足这些带宽需求。这促使我们开展了一项独立调查，以确定适用编解码器的性能要求，最终促成了LC3编解码器的引入，我们将在第5章详细介绍该编解码器。

2.1.1.3 Adding more users

听力损失可能具有家族遗传性，且常与年龄相关，因此家庭中通常会有不止一人佩戴助听器。因此，新的拓扑结构需要支持多名助听器佩戴者。图2.3展示了两人的用例，这两人应体验相同的延迟。

2.1.1.4 Adding more listeners to support larger areas

该拓扑结构还应具备可扩展性，以便多人收听，例如在教室、会议中心、剧院或养老院等场景。这一需求将蓝牙LE音频定位为当今感应线圈（telecoil）的补充解决方案，其提供更多功能且安装更简便。这需要一个蓝牙广播发射器，能够广播单声道或立体声音频流，且范围内任意数量的助听器都能接收，如图2.4所示。

图2.4还表明，有些人仅单耳存在听力损失，而有些人则双耳均有听力损失（且双耳的听力损失程度可能不同）。这意味着可同时广播立体声信号和单声道信号。该图还强调，用户可能佩戴不同公司的助听器来应对双耳听力差异，或一只耳朵佩戴助听器、另一只耳朵佩戴消费级耳塞。

2.1.1.5 Coordinating left and right hearing aids

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

2.1.1.6 Help with finding broadcasts and encryption

使用感应线圈时，用户只有一种获取信号的方式：开启感应线圈接收器以拾取周围感应线圈的音频信号，或关闭接收器。由于一个区域内只能存在一个感应线圈信号，因此用户无需选择要接收的信号。但另一方面，这也意味着无法实现同时广播多种语言等功能。

借助蓝牙技术，多个广播发射器可在同一区域内工作。这带来了显著优势，但也引发了两个新问题：如何拾取正确的音频流，以及如何防止他人窃听私密对话。

为帮助用户选择正确的音频流，让用户能够获取可用音频流的相关信息至关重要，这样他们就能直接跳转至偏好选项。该体验的丰富程度显然会因广播流的搜索方式而异——无论是在助听器、手机还是遥控器上实现搜索，但相关规范需要涵盖所有这些可能性。许多公共广播无需保密，因为它们用于强化公共音频通知，例如下一班公交车的到站时间。然而，其他一些场景则需要隐私保护。在家庭等环境中，用户不会希望接收到邻居家的电视音频。因此，音频流能够加密非常重要，这需要具备向授权用户分发加密密钥的能力。该过程必须安全，但操作要简便。

除了低延迟外，模拟当前助听器的使用场景还带来了其他一些限制。当用户佩戴两只助听器时，无论它们接收的是相同的单声道还是立体声音频流，都需要在25微秒内同步渲染音频，以确保声像稳定。这一点对立体声耳塞同样适用，但当左右设备可能来自不同制造商时，实现起来颇具挑战性。值得强调的是，这里的时间单位是微秒而非毫秒，这种同步精度要求比大多数音频开发人员所习惯的更为严苛。

2.1.1.7 Practical requirements

助听器体积非常小巧，这意味着其按钮空间极为有限。佩戴者虽涵盖各年龄段，但部分老年佩戴者的手指灵活性较差，因此将音量调节和连接控制功能集成到其他更易操作的设备上至关重要。这类设备可能是音频源（通常为用户的手机），而助听器用户也普遍会配备钥匙扣式的小型遥控器——其优势在于能即时响应操作：若想调低助听器音量，只需按下音量键或静音键，无需解锁手机、查找助听器应用程序再进行控制。后者操作耗时过长，并非多数助听器用户青睐的使用体验。他们需要快速便捷的音量与静音控制方式，否则可能会直接摘下助听器，这显然并非理想的使用状态。

助听器在音量方面还有另一项要求，即音量级别（实际为增益）应在助听器上实现。其基本原理是：如果音频流以线路电平传输⁴，就能获得最大动态范围来进行处理。对于正在处理声音的助听器而言，输入信号提供尽可能最佳的信噪比非常重要，尤其是当该信号与来自环境麦克风的音频流混合时。如果在信号源处降低音频增益，会导致信噪比恶化。

助听器与耳塞或耳机的一个重要区别在于，助听器多数时候都处于佩戴状态且持续工作，会放大并适配环境声音，以帮助佩戴者更清晰地聆听。用户不会频繁取下助听器并将其放回充电盒中。一对助听器的日均佩戴时间通常约为9.5小时，部分用户甚至可能佩戴15小时以上。这与耳塞和耳机截然不同——后者仅在用户准备接听/拨打电话或收听音频时才会佩戴。耳塞制造商在充电盒设计上颇具巧思，可促使用户在白天定期为耳塞充电，从而营造出电池续航更持久的假象。而助听器无法采用这种方式，因此设计者需竭尽全力将功耗降至最低。

消耗电量的因素之一是搜索其他设备及维持后台连接。耳塞会收到明确的触发信号——当从充电盒取出并佩戴时，多数耳塞还配备光学传感器以检测是否在耳内，若置于桌面则会进入休眠状态。但助听器始终处于开启状态、持续作为助听设备工作，因此无法获得同样明确的蓝牙连接启动信号。这意味着它们需要在等待事件触发时，与其他设备维持持续的蓝牙连接。这些连接的占空比可以较低，但不能过低，否则可能错过来电，或对启动音乐流媒体应用的响应过慢。由于助听器可能连接多种设备（如电视、手机甚至门铃），此类连接会过度消耗电量，因此需要一种新机制，使其能与多种不同产品快速连接，同时不缩短电池续航，也无需维持持续连接。我们将在3.7节详细探讨这种新型非连接拓扑模型。

2.1.2 Doing everything that HFP and A2DP can do

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

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

2.1.3 Evolving beyond HFP and A2DP

第三轮需求反映出音频和电话应用已超越HFP和A2DP的范畴。如今许多通话属于VoIP5（网络语音通话），且单一设备（无论是笔记本电脑、平板电脑还是手机）同时接入多个不同通话的情况十分常见。蓝牙技术需要一种更优的方式来处理来自多种不同载体的通话。同样，A2DP在制定时并未预见到流媒体及其伴随的搜索需求——因为当时用户拥有本地音乐副本，除了选择本地文件外，很少进行更复杂的操作。如今的产品需要更复杂的媒体控制功能，还需要能够支持语音命令而不中断音乐流。

当今的手机和会议应用程序复杂多样，用户需要处理多种类型的通话以及音频流，这意味着他们会更频繁地在设备和应用程序之间进行切换。HFP和A2DP在架构上的固有差异一直使这一过程困难重重，因此形成了一套最佳实践规则，构成了适用于HFP和A2DP的多配置文件规范（MPS）。然而，MPS本质上只是针对两种用例的权宜之计。新的蓝牙LE音频架构必须超越这一局限，通过设计融入多配置文件支持，以应对不断扩展的用例，实现设备与应用程序之间、单播与广播之间稳健且互操作的过渡。这也导致了对复杂角色切换的摒弃，这种切换在传统蓝牙应用中增加了复杂度。

随着消费领域越来越多人开始了解助听器的感应线圈和广播功能的工作原理，他们逐渐意识到广播技术可能在大众消费领域有一些非常有趣的应用。其中最受关注的是，人们发现它可以用于音乐分享，例如朋友之间通过手机共享音乐、无声迪斯科，或是咖啡店和公共场所的“无声”背景音乐。像为助听器佩戴者提供出行信息的公共广播设施，如今配备蓝牙耳机的人都能使用。我们将在第11章和第12章详细探讨的“音频共享”概念由此诞生。

潜在的新用例开始激增。如果我们能为两个耳塞同步立体声通道，那为何不用于环绕声呢？各家公司热衷于确保蓝牙LE音频支持智能手表和腕带，这些设备可以充当遥控器，甚至成为带有嵌入式MP3播放器的音频源。低延迟特性令游戏界兴奋不已。微波炉可以告知你晚餐何时烹饪完成（你能判断出这个想法源自工程师）。随着企业看到蓝牙LE音频如何使客户受益、如何契合其产品战略以及如何影响语音和音乐的未来使用，用例数量持续增长。

功能的多样性意味着完成该规范耗费了大量时间。令人欣慰的是，过去几年提出的大多数新用例无需我们回溯并重新修订规范——我们发现这些用例已被现有定义的架构所支持。这表明蓝牙LE音频标准的设计颇具前瞻性，既能支持当下的音频应用，也能为未来的新型音频应用提供支撑。

2.1.4 Addressing future audio applications

该规范的制定工作并未停止。蓝牙LE音频规范的发布意味着现在可以设计和制造范围极为广泛的创新产品，但相关工作仍在继续。在未来几年，我们将看到更多规范被采用，不过目前这些规范仍处于保密状态。如果您是蓝牙技术联盟（Bluetooth SIG）的会员或推广会员，可以通过加入助听器工作组、通用音频工作组或音频、电话与汽车工作组来跟进这项工作。采用会员在规范准备好用于原型设计时，将能够提前获取这些规范。

2.1.5 Core requirements to support the hearing aid use cases

在定义了拓扑结构和连接的需求后，显然需要向核心规范中添加大量新功能以支持这些需求。这引发了新一轮的工作，以确定如何在核心规范中最佳地满足这些新需求。

该流程的首要环节是分析能否通过扩展现有蓝牙音频规范来支持新功能，而非在蓝牙低功耗（Bluetooth LE）中引入全新的音频流传输能力。若此方案可行，则能实现与当前音频配置文件的向后兼容性。结论与蓝牙LE首次开发时所做的分析类似：这种方式需做出过多妥协，因此更优选择是基于蓝牙®核心4.1版本进行“白纸一张”的全新设计。

蓝牙®核心规范的提案是实现一项名为等时通道的新功能，该功能可在蓝牙低功耗（Bluetooth LE）中与现有ACL通道并行传输音频流。ACL通道将用于配置、设置和控制音频流，同时传输更通用的控制信息，如音量、电话和媒体控制等。等时通道可支持单向或双向音频流，并且能与多个设备建立多个等时通道。这将音频数据平面和控制平面分离，使蓝牙LE音频具有更高的灵活性。

音频连接的稳健性至关重要，这意味着它们需要支持多次重传，以应对某些传输可能受到干扰的情况。对于单播流，存在ACK/NACK确认机制，因此一旦发送方知道数据已被接收，重传即可停止。对于没有反馈的广播，源端需要无条件重传音频数据包。在研究稳健性的过程中，显然可以改进用于保护LE设备免受干扰的跳频方案⁸，因此这被添加为另一项要求。

广播需要一些新概念，尤其是在设备无需建立连接即可发现广播的方式上。蓝牙低功耗（Bluetooth LE）通过广告帧让设备宣告自身存在。想要建立连接的设备会扫描这些广告帧，然后与发现的设备连接，以获取其支持的功能详情、连接方式——包括传输时间、跳频序列以及具体功能等信息。这需要的信息量远超普通蓝牙LE广告帧的承载能力。为克服这一限制，核心规范新增了扩展广告（EA）和周期性广告序列（PA）功能，允许通过通用数据通道（通常不用于广告传输）的数据包携带这些信息。与此同时，规范还为接收设备新增了相关流程，使其能利用这些信息确定广播音频流的位置并与之同步。

外部设备需协助发现广播流的这一需求，催生了一项新要求，即该设备需能告知接收端如何连接至该流——本质上是让接收端能够向遥控器请求指引并获取连接路径。这通过核心规范中名为PAST（周期性广告同步传输）的功能实现，它是简化广播获取流程的关键。PAST对助听器而言是极具实用价值的功能，因为扫描操作会消耗大量电量。通过将扫描任务卸载至其他设备来最大限度减少扫描，是帮助延长助听器电池续航的有效方式。

针对助听器的需求还促使核心规范增加了其他几项功能，主要围绕性能和节能优化。其一，新编解码器可在主机（Host）或控制器（Controller）中实现。后一种方式更便于硬件集成，通常能效更高。其二，对单次传输或接收的最长持续时间设定限制，这直接影响了等时通道（Isochronous Channels）的数据包结构设计。此举源于多数助听器使用锌空一次性电池——因其具备高能量密度优势，但这种电池化学特性对电流尖峰和高功率持续输出非常敏感。若不加以限制，电池寿命将大幅缩短。这些约束条件最终塑造了等时通道的整体设计。

核心需求的最后两项补充（在开发后期才加入）是等时适配层（ISOAL）和增强属性协议（EATT）的引入。

ISOAL允许设备将来自上层的服务数据单元（SDU）转换为链路层不同大小的协议数据单元（PDU），反之亦然。之所以需要这样做，是为了应对以下情况：设备可能正在为新的LC3编解码器使用推荐的定时设置（该编解码器针对10ms帧进行了优化），同时又要与以7.5ms定时间隔运行的旧版蓝牙设备建立连接。

EATT 是对蓝牙低功耗（Bluetooth LE）标准属性协议（ATT）的增强，允许 ATT 协议的多个实例并发运行。这消除了 ATT 的阻塞限制——在原限制下，每个命令需完成后才能执行下一个命令。

扩展广告功能在蓝牙®核心5.0版本中采用。蓝牙®核心5.1版本通过周期性广告对其进行了增强，而蓝牙®核心5.2版本则引入了等时通道、增强属性协议（EATT）和等时适配层（ISOAL）。这些为所有其他蓝牙LE音频规范奠定了基础。蓝牙®核心规范随后又发布了三个修订版本——蓝牙®核心5.3、5.4和6.0，其中仅包含对等时通道功能的小幅更新，未做重大改动。

2.2 The Bluetooth LE Audio architecture

蓝牙LE音频架构与之前的所有其他蓝牙规范一样，采用分层构建。图2.5展示了这一点，该图显示了与蓝牙LE音频相关的主要新规范模块（将现有关键模块标为灰色或虚线）。

最底层是核心层，包含射频和链路层（统称为控制器），负责通过无线发送蓝牙数据包。核心层之上是主机层，其任务是告知核心层针对特定应用该执行何种操作。控制器与主机的分离源于历史原因，这反映了过去蓝牙射频模块被集成在USB闪存盘或PCMCIA卡中的情况，当时主机作为软件应用在个人电脑上运行。如今，主机和控制器通常集成在单一芯片中。在手机中，协议栈的大部分可能在手机操作系统中实现，制造商通过自身的应用程序接口（API）向应用开发者开放功能。

在主机层中，存在一种名为通用音频框架（GAF）的新结构。这是一种音频中间件，包含所有被视为通用的功能，即可能被多个音频应用使用的特性。核心层和GAF构成了蓝牙LE音频的核心，它们提供了强大的灵活性。最后，在协议栈的顶层，我们有所谓的“顶层”配置文件，这些配置文件为GAF规范添加了特定于应用的信息。

仅使用GAF规范就完全可以构建互操作的蓝牙LE音频应用。GAF内的各个规范经过精心定义，以确保基础级别的互操作性，从而使任意两款蓝牙LE音频设备都能实现音频传输。顶层配置文件规范主要添加特定类型音频应用的专属功能——将GAF中定义为可选的功能设为强制要求，并补充应用专属的功能逻辑。其设计初衷是让顶层配置文件相对简洁，并基于GAF的现有功能构建。在大多数场景下，这些顶层配置文件可视为主要的配置需求集合。

乍看之下，蓝牙LE音频架构似乎很复杂，因为通用音频框架（GAF）内共有18项不同的规范，此外还有扩展的核心层、新的LC3编解码器以及越来越多的顶层配置文件。但这背后是有逻辑的：每项规范都试图封装设置和控制音频流不同方面的特定要素。在本章的剩余部分，我将简要解释每项规范及其相互关联方式。然后在本书的其余章节中，我们将探讨每项规范的具体工作原理及其交互方式。

2.2.1 Profiles and Services

GAF内的所有规范均采用图2.6所示的标准蓝牙LE GATT模型，划分为配置文件（Profiles）或服务（Services）。

在蓝牙低功耗（Bluetooth LE）中，配置文件（Profiles）和服务（Services）可被视作为客户端（Clients）和服务器（Servers）。服务实现在状态⁹所在的位置，而配置文件规范则描述状态的行为方式，包括管理状态的流程。服务规范定义一个或多个特征（characteristics），这些特征可代表独立功能或状态机的各个状态，也可以作为控制点，促使状态机的状态之间发生转换。配置文件针对这些特征执行操作，对其进行读取或写入，并在值发生变化时收到通知。多个设备可各自作为客户端，对一个服务器进行操作。

传统上，在经典蓝牙配置文件（没有对应服务）中，仅存在单个客户端与单个服务器的简单一对一关系，所有内容均在配置文件规范中描述。而在蓝牙LE音频中，一对多拓扑更为常见，尤其是在音量控制和广播源选择等功能中，用户可能拥有多个实现配置文件规范的设备作为客户端。在大多数情况下，这些客户端按先来先服务的原则运行。

蓝牙LE音频中可使用的不同控制配置文件数量推动了对核心规范的EATT增强。配置文件和服务使用属性协议（ATT）进行通信，但ATT假定一次仅发生一个命令。如果同时发生多个命令，第二个命令可能会延迟，因为ATT是一种阻塞协议。为解决这个问题，蓝牙®核心5.2版本中添加了增强属性协议（EATT），允许多个ATT实例同时运行。

图2.7概述了蓝牙LE音频架构，为构成通用音频框架（GAF）的全部18项规范以及当前6项顶层配置文件分别赋予了名称（更准确地说，是一组字母缩写）。虚线框表示协同工作的配置文件和服务集合。大多数情况下，配置文件与服务呈一一对应关系，但基本音频配置文件（BAP）¹⁰和语音控制配置文件（VCP）例外——单个配置文件可作用于三种不同的服务。公共广播配置文件（PBP）和广播音频统一资源标识符（BAU）则属于特殊情况，因为它们均不对应服务，这是广播机制的固有特性之一：当不存在连接时，无法实现传统的客户端-服务器交互。

2.2.2 The Generic Audio Framework

现在我们可以了解通用音频框架（GAF）的组成部分。各种规范之间存在大量交互，这使得很难在它们之间画出清晰的层次结构或一组关系，但大致可以将它们分为四个功能组，如图2.8所示。

这种分组主要是为了便于解释。在蓝牙LE音频的实际实现中，大多数规范之间都存在不同程度的交互。仅使用其中少数几个规范就完全可以打造出可用的产品，但要设计功能丰富且具有互操作性的产品，则需要使用大部分规范。

2.2.3 Stream configuration and management – BAPS

从图2.8的底部开始，我们看到一组由四项规范组成的集合，统称为BAPS规范。这四项规范构成了通用音频框架的基础。其核心是BAP（基本音频配置文件），用于设置和管理单播及广播音频流。作为一种配置文件，它与以下三种服务协同工作：

- PACS（已发布音频能力服务）：用于公开设备的各项能力。

- ASCS（音频流控制服务）：定义用于设置和维护单播音频流的状态机。

- BASS（广播音频扫描服务）：定义用于发现和连接广播音频流以及分发广播加密密钥的流程。

它们共同负责承载音频数据的底层等时通道的设置方式，同时还为LC3编解码器定义了标准的配置集合，以及用于广播和单播应用的相应服务质量（QoS）设置范围。

针对单播和广播场景，分别为每个独立的等时通道定义了状态机。如图2.9的简化状态机所示，这两类状态机均会将音频流从配置状态转换为流传输状态。

对于单播场景，状态机在ASCS规范中定义。该状态存在于服务器的各个音频端点内，而客户端控制则在BAP中定义。对于广播场景，由于发送方和接收方之间不存在连接，客户端-服务器模型的概念就显得有些站不住脚。因此，BAP仅为发送方定义了状态机，且该状态机完全由其本地应用控制。在广播场景中，接收方需要检测流的存在然后进行接收，但无法影响其状态。

多个单播或广播等时通道会按组绑定（我们将在第4章探讨这一内容）。BAP定义了如何针对广播流和单播流组合这些通道组及其构成的等时通道。

仅使用以下三项规范即可打造蓝牙LE音频产品：用于单播的BAP、ASCS和PACS，而广播场景仅需BAP（不过若想通过手机或遥控器辅助查找广播内容，则需添加PACS和BASS）。这类设备的功能会非常有限——仅能完成音频流的建立、传输与停止。但正是凭借这些基础能力，BAPS系列规范为所有蓝牙LE音频设备提供了互操作性基准。即便两台蓝牙LE音频设备采用不同的顶层配置文件，它们仍应能通过BAP建立音频流。虽然功能可能受限，但性能表现应能满足基本需求，从而解决了经典蓝牙音频中存在的多配置文件不兼容问题（在经典蓝牙中，没有共同音频配置文件的设备无法协同工作）。

2.2.4 Rendering and capture control

建立音频流后，用户往往希望控制音量，既包括在耳内渲染的音频流音量，也涉及麦克风的拾音音量。

音量控制是一个颇为复杂的话题，因为存在多个可调节音量的位置——声源设备、助听器、耳塞或扬声器上，或者在其他“远程控制”设备（如智能手表或独立控制器）上。在蓝牙LE音频中，音量的最终增益调节是在助听器、耳塞或扬声器中完成的，而非在编码前的输入音频流上。基于这一前提，音量控制配置文件（VCP）定义了客户端如何管理音频接收器设备的增益。该增益状态在音量控制服务（VCS）中定义，每个音频接收器上都有一个VCS实例。音量可以用绝对或相对值表示，也可以静音。

当发起设备发送多个蓝牙LE音频流时（如耳塞、助听器和扬声器的应用场景），需要第二种服务。VOCS（音量偏移控制服务）实际上充当平衡控制器¹¹，允许调整多个设备的相对音量。这些设备可能在不同设备上渲染音频，例如左右独立的耳塞或扬声器，也可能在单个设备上，如一副耳机或条形音箱。VOCS与音频流传输正交——它不关心多个流的音频内容是否相同，其唯一目的是设置多个渲染设备之间的相对增益。

音频输入控制服务（AICS）认可了如今许多设备能够支持多个不同音频流这一事实。AICS 允许用户控制多个可混合在一起并在耳塞或扬声器中渲染的不同输入。图 2.10 展示了这三种服务如何在具有蓝牙、HDMI 和麦克风输入的条形音箱中使用。

对于助听器而言，其输入可能包括蓝牙音频流、提供环境音的麦克风音频流，以及从音频环路接收信号的感应线圈天线。在任何时刻，佩戴者可能都希望听到这些不同输入的组合，而AICS（音频输入控制服务）正是为了支持这种灵活性而设计的。

音量服务的一个重要特性是，它们会将任何变化通知给运行语音控制配置文件（VCP）的客户端设备。这确保了所有潜在的音量控制器都能实时更新其状态变化，无论该变化是通过蓝牙链路发生，还是由音频接收器上的本地音量控制触发。这确保了它们都对音量状态有同步的认知，因此用户可以从任何一个控制器进行更改，而不会因对当前音量水平的状态认知过时，导致出现任何意外影响。

麦克风控制配置文件（MICP）和麦克风控制服务（MICS）是一对互补的规范，负责控制助听器和耳塞内置的麦克风。如今，这类设备通常配备多个麦克风。助听器既要拾取环境音（这是其主要功能），也要处理通过蓝牙接收的音频。随着耳塞的功能日益复杂，我们越来越多地看到其内置了类似的环境音采集功能，某种程度的“透听”模式也愈发流行——该模式会将环境音与蓝牙音频流混合。

MICP（麦克风控制配置文件）与AICS（音频输入控制服务）及MICS（麦克风控制服务）协同工作，用于控制多个麦克风的整体增益和静音功能。这些规范通常用于控制将通过蓝牙流传输的捕获音频，但也可更广泛地应用。图2.11展示了这些服务的使用方式。

2.2.5 Content control

在明确了音频流的设置与管理方式以及音量和麦克风输入的处理方式后，我们接下来讨论内容控制。我们所收听的内容由蓝牙规范之外的系统生成，可能是流媒体音乐、直播电视、电话通话或视频会议。内容控制规范的作用是允许对音频流进行启动、停止、应答、暂停和选择等操作。这些控制类型此前已嵌入到HFP（免提配置文件）以及与A2DP（高级音频分发配置文件）配套的AVRCP（音频/视频远程控制配置文件）中。在蓝牙LE音频中，它们被拆分为两组规范：一组用于各种形式的电话通信，另一组用于媒体控制。其核心区别在于：电话通信控制关注通话状态（通常反映电话服务的状态），而媒体控制则作用于音频流的状态（包括播放时间、播放方式和选择方式）。由于这些控制与音频流解耦，因此可用于协助控制状态转换，例如在接听电话时暂停音乐播放，并在通话结束后恢复播放。对于这两组规范，相关服务驻留在主音频源设备上（通常是手机、电脑、平板电脑或电视），而配置文件则在接收音频流的设备（如助听器或耳塞）上实现。与渲染和捕获控制类似，多个设备可作为客户端，因此电话和媒体状态可通过智能手表进行控制，而不必局限于耳塞或作为耳塞控制的补充。

媒体控制服务（MCS）驻留在音频媒体源设备上，用于反映音频流的状态。该状态机允许使用媒体控制配置文件（MCP）的客户端将每个媒体源在播放、暂停和搜索状态之间进行转换。最简单的情况下，它可让耳塞实现播放和停止控制。然而，MCS的功能远不止于此，它提供了当今用户期望从内容播放器中获得的所有功能。它还提供更高级别的功能，例如用户可以搜索曲目、修改播放顺序、设置分组以及调整播放速度。该服务定义了可用于识别曲目的元数据结构，并利用现有对象传输服务（OTS）允许客户端在服务器（或更常见的是服务器背后的应用程序）上执行媒体搜索。所有这些意味着，运行媒体控制配置文件的功能复杂设备能够重现音乐播放器的各种控制功能。

电话控制采用类似的处理方式，借助驻留在通话相关设备（通常为手机、电脑或笔记本电脑）上的电话承载服务（TBS），配套的呼叫控制配置文件（CCP）通过写入TBS实例中的状态机来实现对通话的控制。TBS和CCP已突破免提配置文件（HFP）的局限性，这反映了我们如今使用多种形式电话通信的现状。其不再仅聚焦于传统电路交换和蜂窝承载，而是通过支持多种不同类型的承载服务，全面适配基于PC和网络的通信及会议应用。TBS通过通用状态机公开通话状态，支持多线通话、呼叫处理与合并、来电显示、带内/带外环铃音选择，并提供信号强度等通话信息。

TBS和MCS都认可服务器设备上可能存在多个媒体源和多种不同通话应用这一事实。为了适应这一点，两者都可以多次实例化——每个应用实例对应一次实例化。这使得具有互补配置文件的客户端能够分别控制每个应用。或者，也可以使用服务的单个实例，由媒体或通话设备通过其特定实现将配置文件命令导向正确的应用。TBS和MCS的单实例变体分别称为通用电话承载服务（GTBS）和通用媒体控制服务（GMCS），它们分别包含在TBS和MCS规范中。我们将在第9章更详细地探讨这些内容。

2.2.6 Transition and coordination control

接下来我们讨论过渡与协调控制规范。其目的是将其他规范衔接起来，为顶层配置文件提供向下调用的途径，使其无需关注具体的设置细节。

等时通道的一大增强功能是能够向多个不同设备流式传输音频，并实现精确同步渲染。其最常见的应用场景是向左右耳塞、扬声器或助听器流式传输立体声音乐。渲染的拓扑结构和同步由核心规范和BAP处理，但要确保控制操作（如调节音量或连接切换）协同发生则并非如此。而这正是协调集标识配置文件（CSIP）和协调集标识服务（CSIS）的用武之地。

当两个或多个蓝牙LE音频设备需要协同使用时，它们被称为“协调集”，并可通过协调集标识服务（CSIS）实现彼此关联。这使得其他配置文件（尤其是通用音频配置文件CAP）能够将它们视为单一实体。该机制引入了“锁定（Lock）”和“优先级（Rank）”概念，以确保在音频连接切换时（无论是切换至新的单播流还是广播流），协调集中的设备成员始终同步响应。这可避免新连接仅应用于集合中的部分设备——例如电视连接至右耳塞，而手机连接至左耳塞的情况。设计为协调集成员的设备通常在制造过程中即配置为集合成员。

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

通用音频配置文件（CAP）引入了“指挥官（Commander）”角色，该角色整合了可用于远程控制蓝牙LE音频流的功能。指挥官角色是对以往蓝牙规范的重大革新，它允许通过额外设备来影响音频体验，从而实现了音频设备的泛在化分布式远程控制设计。这一功能在加密广播场景中尤为实用——当与广播发射机配合使用时，它为用户提供了获得私密收听体验的途径。我们将在第8章和第12章中详细探讨这些内容。

CAP（通用音频配置文件）利用CSIS（协调集标识服务）和CSIP（协调集标识配置文件）将设备关联起来，确保相关流程同时应用于这两者。它还引入了“上下文类型（Context Types）”和“内容控制ID（Content Control IDs）”的概念，使应用程序能够基于对控制设备、音频数据用例以及可用应用程序的了解，就流设置和控制做出决策。这用于告知不同流之间的过渡，无论是由设备上的不同应用程序触发，还是由不同设备发起的音频连接请求所导致。此功能的许多部分都基于蓝牙LE音频中引入的新概念，这些内容将在第3章中详细解释。

2.2.7 Top level Profiles

最后，在通用音频框架（GAF）规范之上，我们有顶层配置文件，这些配置文件为特定音频用例提供了额外要求。目前，这些顶层配置文件包括： - **助听接入配置文件和服务（HAP 与 HAS）**：覆盖助听器生态系统的应用场景； - **电话与媒体音频配置文件（TMAP）**¹²：规定了更高质量编解码器设置的使用，以及更复杂的媒体和电话控制功能； - **游戏音频配置文件（GMAP）**：专为游戏场景的低延迟音频需求而设计； - **公共广播配置文件（PBP）**：帮助用户选择具有全球互操作性的广播流； - **广播音频统一资源标识符（BAU）**：定义如何通过二维码等带外方式协助广播助手定位广播内容。 PBP 和 BAU 规范的特殊之处在于没有配套服务，这是由广播的性质决定的——在广播场景中，不存在任何用于客户端-服务器交互的连接。

2.2.8 The Low Complexity Communications Codec (LC3)

尽管不属于通用音频框架（GAF）的一部分，但蓝牙LE音频规范包含了一种名为LC3的新型高效编解码器，它是蓝牙LE音频流的强制编解码器。LC3为电话语音、宽带和超宽带语音以及高质量音频提供了出色的性能，并且是BAP（蓝牙音频配置文件）中的强制编解码器。每款蓝牙LE音频产品都必须支持LC3编解码器以确保互操作性，但制造商也可根据需求添加额外的专有编解码器。LC3将音频编码为单流，因此立体声会被编码为独立的左声道和右声道流。这意味着GAF可以将单播流配置为仅向耳塞传输该耳塞所需的音频。发送音乐的广播发射机通常会在其广播中包含独立的左声道和右声道音频流，而各个设备只需接收并解码与它们想要渲染的流相关的数据即可。

2.3 Talking about Bluetooth LE Audio

编写二十多个规范催生了大量新缩写，包括用于指代每个具体规范名称的缩写。随着时间的推移，各工作组形成了不同的称呼方式——有的作为首字母缩略词（按单词发音），有的作为首字母缩写（按字母发音），偶尔也会混合使用。下表汇总了最常用缩写的当前发音，以帮助您理解任何讨论蓝牙LE音频的内容。

2.3.1 Acronyms

以下缩写均按单词发音，或按字母与单词组合发音：

2.3.2 Initialisms

其余缩写仅按组成缩写的单个字母发音，例如：CCP 读作“see - see - pee”，LC3 读作“el - see - three”。

蓝牙LE音频中最常见的首字母缩写包括：ACL、AD、ASCS、BMR、BMS、BR/EDR、CCID、CCP、CG、CSS、CT、CTKD、EA、FT、GMCS、GSS、GTBS、HA、HCI、IA、IAC、IAS、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。这些术语的解释均收录于术语表中。