第6章-CAP和CSIPS

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

在蓝牙® LE Audio spec集的通用音频框架中，四个 BAPS spec（基本音频profile、音频流控制服务、广播音频扫描服务和发布的音频功能服务）承担了大部分繁重工作。如果您实现这四个spec，您几乎可以构建任何单播或广播应用程序。但是，它们被设计为尽可能通用，这意味着有多种不同的方式将各个部分组合在一起。 CAP——通用音频profile，定义了一组程序来建立通用方式来执行在Initiator和一个或多个Acceptor之间设置音频流所需的所有日常操作。对于大多数开发人员来说，CAP 提供了他们构建应用程序的接口。

CAP 与我们在第 3 章中遇到的内容控制、用例和渲染控制概念相关联。它定义了在流配置和建立过程中何时需要使用这些概念。当LE audio 设备在连接内的不同用例之间转换或与不同设备建立连接时，这也是防止多profile问题的关键。

CAP 为流程带来的另一件事是协调。当今蓝牙音频的最大市场是耳塞——两个独立的设备需要像一体一样工作。 BAPS spec处理各个流。当Initiator连接到多个Acceptor时，CAP 制定了管理流的规则，使用协调集标识profile和服务将它们绑定在一起。

最后，CAP 定义了commander角色，它将广播从简单的感应线圈替换提升为高度灵活的音频分配解决方案。

在本章中，我将概述 CAP 过程及其使用方式。从本质上讲，您可以将 CAP 视为一本食谱书。 BAPS spec定义了音频流的所有成分，CAP 告诉您每个过程使用哪些成分，以及使用它们的顺序。大部分细节将在以下章节中介绍设置单播和广播音频流，在这里我们将看到 CAP 如何增强和利用 BAPS 中已有的流控制和管理程序。但在我们开始 CAP 之前，了解 CSIP 和 CSIS 很重要。

6.1 CSIPS—Coordinated Set Identification Profile and Service

由于 A2DP 专为流式传输到单个设备而设计，因此当今市场上向多个设备发送音频的每个蓝牙解决方案都使用某种专有方法使它们协同工作，无论它们是一对耳塞、助听器还是扬声器。LE audio 需要定义一个标准方法来执行此操作，以便可以一起使用任何产品组合。问题不仅在于确保他们可以一起控制音量，还在于确保如果您更改提供音频流的设备，例如当您在看电视时有电话打断您，那么两者都会离开和右耳塞同时改变与您手机的连接。这一要求导致了协调集的概念。

协调集标识服务在形成一个组（称为协调集）的设备上实例化，其中组成员以协同方式执行特定用例。一个典型的例子是一对耳塞。这些spec不仅限于音频设备——它们同样可以用于医疗传感器组，例如心电图贴片，其中数据是从单独的传感器收集的。这些设备的所有功能也不需要完全相同，但应该有一个功能。例如，在一对耳塞中，共同的特点是它们都会渲染音频流，但只有一个需要有麦克风。

对于一对耳塞，协调执行四个主要功能：

• 它识别协调集的成员，即左右耳塞
• 它用于对两个设备应用音量控制和静音
• 它用于确保它们都接收来自同一音频源的音频流（流本身通常是不同的，左右，但这与 CSIPS 无关，并且
• 它允许设备锁定对耳塞的访问，防止其他设备访问它们。

CSIP 定义了两个角色：

• 作为协调集成员的设备是集成员，并且
• 发现和管理协调集的设备是集协调器。

集合成员角色本质上是一个被动角色——它只是声明它是集合的一部分。 Set Coordinator 不仅找到成员，而且将这些知识传递给其他过程，以确保这些过程作用于集合的所有成员。

CSIS 要求协调集的每个成员都包含可解析集标识 (RSI) AD 类型，这允许client设备识别它是协调集的成员。这意味着必须有两个或更多的 Acceptor 需要被找到。 RSI 是一个随机的六字节标识符，它随时间而变化。这降低了有人跟踪您的蓝牙产品的风险。

一旦client设备（可以是Initiator或commander）与暴露 RSI AD 类型的设备建立连接，它就会与它发现的集合成员配对并绑定，并读取其集合身份解析密钥 (SIRK) 特征。 SIRK 是一个 128 位随机数，对协调集的所有成员都是通用的，client可以使用它来解码可解析集标识。它在设备的生命周期内不会改变。 SIRK 通常在制造过程中被编程到构成协调集的所有设备中。LE audio spec没有指定设置或更改的方法，因此如果产品需要在其生命周期内添加到协调集，例如更换丢失或损坏的耳塞时，制造商将需要确定方法来实现这一点。

client还需要读取 Coordinated Set Size 特征，它告诉它在该 Coordinated Set 中有多少设备。然后，它通过使用 CSIP 中定义的集合成员发现过程继续查找集合的其他成员。这涉及client设备寻找其他暴露 RSI AD 类型的acceptor，连接和配对它们并读取它们的 SIRK 特征。如果 SIRK 与第一个协调设备具有相同的值，则它是同一集合的成员。如果不同，client设备应放弃配对并寻找具有 RSI AD 类型的下一个设备并检查其 SIRK 特征值。当找到所有集合成员时，集合成员发现过程结束，该过程达到特定于实现的超时（通常大约十秒），或者它被应用程序终止。如果Initiator或commander无法找到所有成员，他们可以继续找到已找到的成员，但应继续尝试寻找失踪的成员。

如果您要运送作为协调集一部分的acceptor，则 CAP 要求在每个设备中实现 CSIS 中定义的所有四个特征。这些如表 6.1 所示。

Characteristic Name	Mandatory Properties	Optional Properties
Set Identity Resolving Key (SIRK)	Read	Notify
Coordinated Set Size	Read	Notify
Set Member Lock	Read, Write, Notify	None
Set Member Rank	Read	Notify

Table 6.1 Coordinated Set characteristic properties for use with CAP

目前，没有 CAP 过程使用 Set Member Lock 或 Rank 特性，尽管它要求它们在 Acceptor 上实现。

设置成员锁的原因是，当client写入该特征时，锁赋予该client对该acceptor上的功能的独占访问权限。 Lock 控件的哪些功能由更高层的应用程序定义。实现者在使用 Lock 时应该小心，因为它可以防止其他 Commander 或 Initiator 访问 Acceptor。当client不再需要独占访问时，它应该释放锁。

等级是通常在制造时分配的值，用于为协调集的每个成员提供唯一编号。它不意味着任何优先级，而是协调集中的唯一正整数，用于确保所有client以相同的顺序将其操作应用于集合的成员。 Rank 用于 CSIP 中的有序访问过程。这表明，当出于任何原因应用锁定时，client应该从它知道具有最低等级的集合成员开始，然后按照等级的升序数字顺序通过协调集合的其他成员。这可以防止两个不同的client同时对不同的集合成员应用锁的竞争条件。 Rank 值通常在制造过程中设置。

Ordered Access 过程也被 CAP 用作运行任何 CAP 过程的前导。它检查是否有任何 Acceptor 被锁定，并且只有在确定没有任何集合成员具有锁定集时才继续执行 CAP 过程。然后它按照 Rank 递增的顺序对每个 Acceptor 应用 CAP 过程。

6.2 CAP—Common Audio Profile

正如我上面所说，CAP 可以被视为所有LE audio 的配方书，将所有其他spec汇集到五个主要程序集中，这些程序定义了一切工作的方式。上层profile，如 HAP、TMAP 和 PBP 然后参考这些 CAP 程序，为其特定用例添加额外的要求。

CAP 是定义我在本书中使用的Initiator、Acceptor和commander角色的地方。虽然只有Initiator和Acceptor可以参与音频流，但 CAP 描述了所有这三个角色如何可以包含来自其他通用音频框架spec的一系列组件。这些列在表 6.2 的矩阵中，其中显示了强制、可选、有条件和排除的要求。条件特性通常被要求用于其他特性的特定组合，并且要求角色支持多个可选组件中的至少一个。不允许排除的组合。所有这些组合的全部细节可以在 CAP 的表 3.1 中找到。

带有破折号 (-) 的框是可以在设备中实现的功能，但不在 CAP 程序的范围内。

6.2.1 单播流管理的CAP程序

管理流的 CAP 程序可分为三类。第一个是一组用于单播流的三个程序，它们在很大程度上是不言自明的：

• Unicast Audio Start procedure
• Unicast Audio Update procedure
• Unicast Audio Stop procedure

这些过程涉及Initiator和Acceptor，因为设置每个单播流使用命令和响应序列。

6.2.2 广播流传输的CAP程序

第二组三个程序用于广播流：

• Broadcast Audio Start procedure
• Broadcast Audio Update procedure
• Broadcast Audio Stop procedure

广播音频开始、停止和更新过程仅由Initiator 使用，因为它是单方面设置的，不知道是否存在任何Acceptor。

6.2.3 广播流接收的CAP程序

为了补充 Initiator 的广播程序，第三组流管理程序是为想要获取广播音频流的 Acceptor 提供的，为我们提供了两个程序：

• Broadcast Audio Reception Start procedure
• Broadcast Audio Reception Ending procedure

Acceptor没有广播音频更新过程，因为Acceptor是广播中的被动实体，它只消耗音频流。它不能做任何事情来更新广播流的内容，因此没有广播音频接收的更新过程。

6.2.4 流切换的CAP程序

CAP 包括两个专门用于流切换的过程，其中Initiator 希望在传输单播和广播音频流之间转换（反之亦然）。这些是：

• Unicast to Broadcast Audio Handover procedure
• Broadcast to Unicast Audio Handover procedure

这些非常重要，因为它们描述了音频共享用例，用户可以从收听手机或音乐源的私人流过渡到通过将其转换为广播来与朋友共享。尽管 CIG 到 BIG 之间的传输拓扑发生了变化，但原始 Initiator 保留了对 Audio Stream 和用户的 Acceptor 的控制。

切换过程之所以重要，是因为大多数Initiator 和Acceptor没有资源来处理并发的单播和广播流。对于高可靠性 QoS 设置，根本没有足够的空中传输时间来完成这两项工作。这意味着initiator通常需要在开始广播流之前停止其单播流，即使对于 24kHz 的采样率也是如此。为了确保主要用户的连续性，即与朋友共享音频的用户，Initiator 必须将相同的Context类型应用于新流。在大多数情况下，拥有 Audio Source 的主要用户希望继续控制流，因此尽管现在广播了音频流，但他们将保持其 ACL 链接并将新的广播音频流与相同的内容控制 ID 相关联（ CCID）他们用于单播流。

在实践中，在此切换过程中可能会出现短暂的传输间隙，这在与 Initiator 链接的原始 Acceptor 上会很明显。虽然实现可以尝试最小化这些，但通过向用户添加一个简单的通知来隐藏它们可能更简单，“请稍候，我们将转移到音频共享”。

6.2.5 捕获和渲染控制的CAP程序

除了 Audio Streams 的四组程序外，CAP 还将音量和渲染控制与五个 Capture 和 Rendering Control 程序联系在一起，这些程序也是不言自明的：

• Change Volume procedure
• Change Volume Offset procedure
• Change Volume Mute State procedure
• Microphone Mute State procedure
• Change Microphone Gain Settings procedure

6.2.6 其他 CAP 程序

除了音频流、捕获和渲染控制过程之外，CAP 还定义了一组与上面列出的音频流过程一起使用的过程。第一个，我们在上一节中遇到过，是协调集成员发现过程，由发起方在设置单播流之前执行，由发起方或commander在调整音量或捕获设置之前执行一个协调集。一旦已知协调集的成员，CAP 总是在任何其他 CAP 过程之前应用 CSIP 有序访问过程。第二个是分发 Broadcast_Code 过程，它定义了如何为加密的私有广播流分发广播代码。

6.2.7 Connection establishment procedures

除广播用例外，LE audio 使用与其他 LE 应用程序相同的外围连接程序，用于设备发现、LE ACL 连接和绑定。 BAP 的第 8 节定义了程序，参考核心spec中的相关部分，并提供了用于扫描间隔、扫描窗口和连接间隔的推荐值，以实现快速设置和降低功耗的情况。这些都是通用访问profile（GAP）中定义的标准连接过程，所以我不会在这里花更多的时间。

CAP 的第 8 节扩展了 BAP 要求，并考虑了多绑定情况，其中 Acceptor 与多个 Initiator 绑定（例如，电话和电视）。它还引入了两种新模式，反映了 Initiator 和 Acceptor 都可以做出连接决策，以支持“Sink led Journey”的概念。这些是“立即需要音频相关外设”模式和“准备好音频相关外设”模式。

6.2.7.1 立即需要音频相关外设 (INAP) 模式

当 Initiator 需要连接到 Acceptor 时使用 INAP 模式，通常是因为用户操作（例如按下按钮）或外部操作（例如来电）。由于这通常是一个高优先级响应，因此发起方应使用 BAP 第 8 节中的快速设置参数值进行连接。发起方应确定响应的Acceptor是否是协调集的成员，如果是，则发现并连接到所有其他集合成员。如果有多个 Acceptor 响应，则 Initiator 应向用户提供可用选项。

6.2.7.2 Ready for Audio related Peripheral (RAP) 模式

与 INAP 相对的情况是 RAP 模式，在这种模式下，Acceptor 正在寻找 Initiator。它通过传输包含描述它想要支持的用例的Context类型的目标公告来发出信号。如果Initiator 可以支持它，它应该尝试连接。在 RAP 模式下，initiator应使用降低的功率参数值进行连接，如 BAP 第 8 节所述。一旦连接到发送目标通知的acceptor，initiator应确定acceptor是否是协调集的成员，如果是这样，发现并连接到所有其他集合成员。

CAP 的表 8.4 中描述了 RAP 或 INAP 模式下发起方对不同形式通知的响应范围。

6.2.8 处理缺失的集合成员

在某些情况下，Initiator 读取了协调集成员的协调集大小特征，尝试定位其他成员并发现一些成员丢失。这可能发生在开始设置音频流时，或者在会话过程中，当Initiator 检测到与其中一个Acceptor的链路丢失时。可能是因为其中一个或多个物理丢失、超出范围或电池已耗尽。发生这种情况时，发起方应尝试查找丢失的成员，但不应停止连接过程，也不应终止任何现有流。相反，它应该定期尝试查找丢失的集合成员，并在发现它们后通过重新建立连接来添加它们。

如果成员丢失，实现可以决定调整单播音频流的内容。例如，如果您的手机一直将立体声音乐流传输到一组协调的左右耳塞，并且与其中一个耳塞的连接消失，它可能会决定用下混单声道流替换剩余的流。但是，这种行为在LE audio 中没有指定，并且是特定于实现的，重试节奏和尝试查找丢失的协调集成员的任何超时也是如此。这不应该影响Context类型，因为用例保持不变。

-oOo-

通用音频profile可能最好概括为一个profile，它说“这是如何连接”和“为您正在处理的所有流执行此操作”。因此，它汇集了所有其他通用音频框架spec，为上层profile提供了一组通用程序。随着在 GAF 中开发更多spec，CAP 将扩展以包括它们。

在接下来的几章关于设置单播和广播流以及捕获和渲染控制的内容中，我们将遇到所有这些 CAP 程序。大多数开发人员会发现自己使用这些过程，而不是底层的 BAP 过程，因为 CAP 过程是由顶层 profile引用的。但是，了解 BAP 程序以及用于设置和管理流的参数是一个有用的练习，可以帮助您了解LE audio 世界中的一切如何组合在一起。这就是我们接下来要做的。