第3章-蓝牙®LE audio新概念_手机设置呈现延迟(presentation delay)

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

为了给设计师提供他们需要的灵活性，新的蓝牙LE audio规范引入了一些重要的新概念。在本章中，我们将看看它们的作用以及为什么需要它们。由于这些特性与规范紧密地结合在一起，当我们深入研究核心和GAF的细节时，下面的一些描述将变得更加清晰。但是，在这个阶段介绍它们是有用的，因为它们在后面的大部分内容中都有。

3.1 Multi-profile设计

正如我们所看到的，蓝牙经典音频面临的挑战之一是多profile问题，用户可以在流媒体音乐、打电话和语音识别之间切换。随着音频用例的复杂性不断增加，这个问题不会得到改善。两个成功的经典蓝牙音频profile-Hands-Free Profile (HFP)和music streaming (A2DP)，在设计的时候，用户被假定使用其中一种，当他们从电话转移到音乐时，开始新的、独立的会话。很快就发现这些不是独立的功能，但电话用户会期望一个用例会中断另一个用例。多年来，该行业已经制定了解决这个问题的规则和方法，最终在 2013 年发布了多profile规范 (MPS)，该规范主要收集了这些profile之间常见转换的规则集。

多profile规范不是特别灵活，也没有预见到新用例的出现，例如语音识别、语音助手和 GPS 卫星导航的中断。 基础规范也不是特别通用。尽管 HFP 已经经历了多个版本并产生了大约 20 个补充规范，以解决汽车与电话交互的特定方面，但它仍然难以跟上非蜂窝 VoIP 电话应用的步伐。它和 A2DP 都没有充分解决音频不断变化的性质，用户在一天中连接到多个不同的音频源，并且可能还拥有多个不同的耳机和耳塞。

从一开始，Bluetooth LE Audio 的开发理念就是支持“多profile设计”。它认识到用户可能有多个耳机和音频源，以一种特殊的方式不断改变连接。广播音频的添加使这一点变得更加重要，因为预计在场馆、商店、休闲设施和旅行中广播的使用将增加用户每天可能进行的不同连接的数量。显然，提供使用户体验无缝的工具很重要。

3.2 Audio Sink 引领之旅

除了这些需求之外,人们还意识到手机不一定是音频宇宙的中心,在蓝牙经典音频规范的发展过程中,这是一个默认的假设。随着越来越多的不同音频源变得可用，重要的是要考虑用户在一天中如何连接他们的耳塞或助听器。这颠覆了以手机为中心的音频世界的感知视图，取而代之的是 Audio Sink引领之旅的概念。

在这种方法中，手机不再是您所听内容的仲裁者。相反，它假设用户越来越有可能全天佩戴一副助听器或耳塞，不断更换他们的音频源。它可能从一个闹钟开始，然后是让你的语音助手打开你的收音机、从公交车站获取信息、对你的电脑进行语音控制、接听电话、门铃的打扰以及在你得到的时候在电视前放松回家，直到微波炉告诉你晚餐准备好了。这种关于谁在控制的概念转变从助听器佩戴者的经验中汲取了很多，他们通常在一天中的大部分时间都佩戴助听器。在大部分时间里，助听器在没有任何蓝牙链接的情况下工作，只是聆听和增强佩戴者周围的声音。但佩戴者可以将其连接到大量的音频源设备，比如，超市收银机、公共交通信息、剧院和礼堂和电视，以及支持蓝牙经典音频的手机和音乐播放器。一旦它被广泛使用，更多的消费者可能会使用它的功能。

当然，手机仍将是主要的音频来源，但个人电脑、笔记本电脑、电视、平板电脑、Hi‑Fi 和语音助手也越来越要。从门铃到烤箱等一系列智能家居设备也加入了他们的行列。与此同时，消费者正在购买更多耳机。拥有一对睡眠耳塞、一组耳塞、一对立体声耳机和条形音箱或蓝牙扬声器的情况并不少见。随着潜在组合的增加，用户界面能够适应这种不同连接范围以及它们之间的转换至关重要。

3.3 术语

蓝牙 LE audio规范的不同部分对发送和接收设备以及它们的作用使用不同的名称。每个规范都将这些称为角色，因此当我们从核心转到顶层profile时，我们将为每个设备积累至少四个不同的角色。这有一个很好的理由，因为堆栈的每一步都会在这些角色中产生更多的特异性，结果是设备可以实现特定的组合来实现目标功能。但他们可能会感到困惑。

Core 指的是 Central 和 Peripheral 设备，Central 设备发送命令，Peripheral 响应。在 BAP 中，它们被称为client和server角色。向上移动一层，CAP 将它们定义为Initiator和Acceptor角色。 Initiator 角色存在于 Central 设备中，它负责设置、调度和管理 Isochronous Streams。

Acceptor是参与这些流的设备 通常是助听器、扬声器和耳塞。总是有一个 Initiator，但可以有多个Acceptor。不同的命名法如图 3.1 所示。

我将大部分时间使用 Initiator 和 Acceptor 名称（即使它们在技术上是角色），因为我认为它们最能解释蓝牙 LE audio的工作方式。 Initiator 和 Acceptor 都可以同时传输和接收音频流，并且它们都可以包含多个蓝牙 LE audio接收器和源。要记住的重要一点是，Initiator 是执行 Isochronous Streams 的配置和调度的设备，Acceptor 是接受这些流的设备。该概念适用于单播和广播。我还会做另一个缩写。由于只有 Initiator 可以广播音频流，我将少说几句，并将充当广播源的 Initiator 称为 Broadcaster，除非需要明确说明 。

在这一点上，有必要稍微转移一下看看蓝牙 LE audio中使用的一些术语。这将介绍一些我们还没有讨论过的特性，我们将在第 4 章讨论等时流时详细介绍这些特性。 在整个规范中，有很多不同的名称和短语来描述通道和流。根据您所查看的规范，它们有一些非常不同的含义，有时甚至略有不同，但我试图在图 3.2 中捕获主要的含义。

该图显示了从左到右的音频数据的概念传输。在最左边，我们有音频进来，通常是模拟信号。它显示为音频输入。 在另一端，我们看到音频在 Audio OUT 处呈现，它可能位于扬声器或耳塞上。这两个点的音频称为Audio Channel（两端是同一个Audio Channel），这相当于在MP3播放器和扬声器之间的连接连接时所携带的东西。音频通道在 BAP 中定义为单向音频流，进入蓝牙设备的输入端，然后从另一端流出。 （实际上，“输出”通常会直接进入您的耳机传感器或扬声器） 。音频通道的输入和输出的细节是特定于实现的，并且超出了蓝牙规范。音频是什么以及在无线传输和解码之后如何处理音频超出了规范的范围 。

音频输入如何传输到音频输出是蓝牙规范中定义的。它们由图 3.2 中的虚线框表示。 音频通过新的LC3编解码器编码和解码,除非实现需要使用特定的附加编解码器。可以使用其他编解码器，但所有设备都必须支持一些基本的 LC3 配置，这些配置在 BAP 中定义，以确保互操作性。编码器生成编码的音频数据，该数据进入等时流的有效负载。

一旦音频数据被编码，它就会被放入 SDU（服务数据单元）中，核心转换成 PDU（协议数据单元）传输到接收设备。 收到 PDU 后，将其重构为 SDU 以传送给解码器。等时流是用于描述 SDU 传输的术语，封装在PDU 中，从编码器输出到解码器输入。它包括同步多个等时流所需的重传和任何缓冲。等时流上的编码音频数据流在 BAP 中定义为音频流，并且与音频通道一样，始终是单向的。不同术语的关系如图 3.3 所示。

核心将服务于同一应用程序的等时流放在一个同步组中。对于单播流，称为连接同步组 (CIG)，其中包
含一个或多个连接等时流 (CIS)。对于Broadcast，它是一个广播同步组 (BIG)。当一个等时组中存在多个等时
流，沿同一方向传输音频数据时，预计unicast 流在应用层彼此之间存在时间关系。时间关系是指预期同时渲染或捕获的音频通道。一个典型的应用是将左右立体声流渲染到两个单独的耳塞中，并从它们的麦克风中返回一个或两个返回流，这突出了一个事实，即 CIG 或 BIG 可以包含传输到多个设备的等时流。蓝牙 LE audio的设计非常灵活，这意味着有时会有不同的处理方式。举个例子，如果我们看一下从手机到耳机的简单连接，我们需要一个音频流在每个方向上传输。一种方法是为每个方向建立单独的 CIS。

在图 3.4 中，我们可以看到两个 CIS，一个传出的（CIS 0）和一个传入的（CIS 1），它们都包含在同一个 CIG 中。我们可以通过使用单个 CIS 来优化它，如图 3.5 所示，该图显示了单个双向 CIS，在同一个CIG 中双向传输音频数据。我们将在下一章中确切地看到它是如何工作的。

这两个选项都是允许的；由应用程序决定哪个最适合其使用。在大多数情况下，双向优化将是一个选
择，因为它可以节省通话时间。

图 3.6 显示了一个典型应用，其中一个 CIG 包含两个 CIS，它可能将一部手机连接到一对耳塞，但返回麦克风仅在一个耳塞中实现。它显示了 CIS 0，这是一个双向 CIS，将电话通话中的音频传输到耳塞，并将耳塞麦克风的音频传输回手机。CIS 1 将音频流从手机传送到另一个耳塞。由应用程序决定发送的是立体声流还是单声道。在后一种情况下，相同的单声道音频数据通过 CIS 0 和 CIS 1 分别发送到两个耳塞。

3.4 Context类型

为了决定他们想要连接到哪些音频流，设备需要更多地了解这些流包含什么或它们的用途。已引入Context类型来描述当前用例或与音频流相关的用例。 它们的值在通用音频的蓝牙分配编号文档中定义。 Initiator 和 Acceptor 都可以使用Context类型来指示他们想要参与的活动或连接类型，并且适用于单播和广播。

使用蓝牙经典音频profile，central和peripheral之间的对话基本上是“我想建立一个音频连接”，没有关于它是什么的更多信息。由于 HFP 和 A2DP profile本质上是单一用途的profile，这不是问题，但在蓝牙 LE audio中，音频流可用于铃声、语音识别、播放音乐、提供卫星导航指令或许多其他应用程序，了解更多关于请求流的预期原因会很有用。这就是Context类型的用武之地。

正如我们稍后将看到的，Context类型在单播流配置过程中用作可选元数据。 Acceptor 可以公开它准备在任何时候接受的Context类型 。例如，如果助听器佩戴者正在进行他们不想被打断的私人（非蓝牙）对话，他们可以将助听器设置为对与“铃声”Context类型关联的流不可用。这意味着助听器会默默拒绝来电。这比让他们的手机静音更普遍，因为通过使用Context类型，他们将拒绝来自他们连接的任何电话的来电，或来自任何其他连接设备的 VoIP 呼叫。他们还可以在通话时设置«铃声»Context类型，以防止任何其他通话中断当前通话。这可以在每个设备的基础上完成，这意味着您可以将来电限制在一个特定的电话上，从而为 Acceptor 提供一种强大的方法来控制哪些设备可以请求音频流。

Initiator在尝试建立音频流时使用Context类型，通知Acceptor相关的用例。如果该Context类型在接受器上设置为不可用，则终止配置和流建立过程。这发生在设置等时流之前的 ACL 链接上，这意味着这些决定可以与现有音频流并行发生而不会干扰它，无论请求是来自当前提供流的设备还是来自另一个Initiator想要建立或替换现有流。现有音频流是单播还是广播并不重要，这意味着使用广播音频流收听电视的助听器用户可以使用Context类型来防止其当前流被任何电话干扰。

目前在 Generic Audio Assigned Numbers 文档中定义了十二个Context类型，它们在Context类型的两个八位字节位域中公开，如表 3.1 所示，每个位代表一个Context类型。这允许在任何时候使用多个值。

Table 3.1Currently defined Context Types

其中大部分是显而易见的，但有两个Context类型值得特别注意：«Ringtone» and «Unspecified»

«Ringtone» Context类型用于通知来电，但仅适用于需要设置音频流的 inband15 铃声的情况。如果用户已经接收到来自与来电不同的设备的音频流，这可能是有问题的。为了在不丢弃当前音频流的情况下向用户发出来电信号，将需要至少一个耳塞从第二个Initiator建立单独的单播流。在实践中，许多 Acceptor 不太可能拥有同时支持来自不同 Initiator 的并发流的资源。 Acceptor 可以丢弃当前的音频流以切换到带内铃声，但如果他们随后拒绝呼叫，则需要恢复原始音频流。在大多数情况下，提供带外铃声可能会带来更好的用户体验，该铃声由耳塞使用 CCP 和 TBS 生成。用户可以听到这种混合到他们现有的音频流中的声音，并决定是接受还是拒绝呼叫。如果他们拒绝呼叫，他们可以继续收听他们的原始流。在大多数情况下，«铃声»最好用于管理是否允许设备通过来电中断当前的音频应用程序。我们将在第 9 章介绍如何处理带外铃声。

«Unspecified» Context类型是一个包罗万象的类别。每个 Acceptor 都必须支持«Unspecified» Context类型，但不需要使其可用。当接受器确实将“Unspecified” Context类型设置为可用时，它表示它将接受任何Context类型，而不是它明确表示不支持的Context类型。随着实施者习惯于Context类型，一些人将使用它来允许central（通常是电话）以与 A2DP 和 HFP 相同的方式负责音频用例。仅将“Unspecified”设置为可用的接受器实际上允许手机完全控制它发送的内容 。我们将在第 7 章更详细地讨论 Supported 和 Available 的概念。

所有的Context类型都是相互独立的。使用其中任何一个并不意味着或要求需要支持另一个，除非该要求是由顶层profile强加的。例如，对«Ringtone» Context类型的支持通常并不意味着或需要对«Conversational» Context类型的支持，因为«Ringtone»本身可以用作分机铃，以提醒有听力损失的人来电拨打固定电话。

Initiator 和 Acceptor 都使用Context类型来提供有关用于流的用例的信息，从而允许它们决定是否接受流。为了实现这一点，它们被用于一系列特征和 LTV16 元数据结构中。您会发现它们在以下地方以这种方式使用：

• Supported_Audio_Contexts characteristic [PACS 3.6]
• Available_Audio_Contexts characteristic [PACS 3.5] (also used in a Server announcement – [BAP 3.5.3])
• Preferred Audio Contexts LTV structure (metadata in a PAC record) (see also [BAP 4.3.3])
• Streaming Audio Contexts LTV structure (metadata used by an Initiator to label an audio stream) [BAP 5.6.3, 5.6.4, 3.7.2.2]

一个音频流可以与多个Context类型相关联，尽管其意图是Context类型值代表当前用例。 Streaming Audio Contexts metadata具有允许设备在用例更改时更新位域值的过程。

这通常用于将已建立的流用于多个用例的情况。一个例子是音频源混合来自不同应用程序的音频，例如可能中断音乐的卫星导航消息。在这种情况下，继续使用相同的流是有效的，假设它的 QoS 参数是合适的，并且只是更新当前的 Context Type 值。

3.5 Availability

与蓝牙经典音频相比，低功耗蓝牙音频支持更多的可能性和组合。为了使设备能够对他们正在做的事情做出明智的选择，他们不仅需要能够告诉对方他们正在参与的用例（这就是Context类型的原因），而且还需要能够告诉对方他们正在参与的用例。以后有兴趣参加。这就是Availability的用武之地。

正如我们在上面看到的，Acceptor 使用Context类型来表示它们是否可以参与用例。这是通过两种方式实现的。 Acceptor 使用 PACS 中定义的 Available_Audio_Contexts 特性来声明其支持的音频Context类型中的哪些当前可用于建立音频流。音频源，无论是Initiator还是Acceptor，也在其编解码器配置的metadata中使用 Streaming_Audio_Contexts LTV 结构，以通知音频接收器与音频流相关联的用例。

想要建立单播音频流的蓝牙 LE audio设备也可以使用Context类型来表示它们的Availability，甚至可以在它们的广告 PDU 中包含 Streaming_Audio_Contexts LTV 结构来启动音频流。以类似的方式，作为广播者的Initiator将其包含在其周期性广告的metadata部分中，以便广播接收器和广播助手可以从他们不感兴趣的acceptor中过滤掉他们想要的用例。

对于Broadcasters，您应该注意，如果 Streaming_Audio_Contexts 字段不存在于编解码器 ID 的metadata中（我们将在第 4 章中介绍），它将被解释为意味着唯一的 Supported_Audio_Contexts 值是«Unspecified»，因此每个广播Sink 可以同步到它，除非他们专门将 «Unspecified» 设置为不可用。

3.6 Audio Location

对于之前的每个蓝牙音频spec，都有一个蓝牙 LE audio源和一个蓝牙 LE audio接收器。音频流作为单声道或立体声发送，并留给音频接收器来解释它是如何呈现的。蓝牙 LE audio旨在解决具有多个扬声器或耳塞的应用。它能够通过仅向其发送所需的音频流来优化每个音频接收器的通话时间。一般来说，对于一对耳塞，左耳塞只接收左音频流，右耳塞只接收右音频流。这意味着每个音频接收器都可以最大限度地减少其接收器的开启时间，从而降低其功耗。

为了实现这一点，设备需要知道它们要接收的空间信息，例如，来自立体声输入的左流或右流。他们通过指定一个音频位置来做到这一点。这些在蓝牙通用音频分配编号中定义，并遵循CTA-861-G’s Table 34 codes 的分类用于扬声器放置。这些值表示为四字节宽位域中的位。最常见的音频位置如表 3.1 所示。

Table 3.2 Common Audio Location values

每个可以接收音频流的接受器都必须设置至少一个音频位置——不允许将整个位域留空。音频位置通常在制造时设置，但在某些情况下，它可能由用户更改 - 例如，扬声器可能具有应用程序或物理开关来将其设置为左前或右前。

请注意，单声道不是位置，因为单声道是流的属性，而不是物理渲染设备。单声道扬声器通常会设置左前和右前音频位置。 Initiator 将确定 Acceptor 支持的流的数量以及可用扬声器的数量，并决定是发送缩混的立体声流（即单声道）还是它假设扬声器可以缩混为单声道的立体声流.Broadcasters将通过将其标记为左前和右前来表示单声道流。我们将在第 5 章中进一步了解音频位置是如何使用的，但它会将我们带到通道分配。

3.7Channel分配（复用）

您始终知道蓝牙经典音频profile中传输的是什么。 HFP 承载单声道音频流，A2DP 使用 SBC 编解码器的四声道模式传输单声道、双声道、立体声或联合立体声编码流。蓝牙 LE audio更加灵活，允许 CIS 或 BIS 包含一个或多个多路复用到单个数据包中的通道，仅受可用带宽的限制。

采用这种方法的原因是，作为所有蓝牙 LE audio实现的强制编解码器的 LC3 是单通道编解码器。这意味着它将每个音频通道分别编码为固定长度的离散帧。使用 SBC，将左右音频通道组合成单个编码流的联合立体声编码很受欢迎，因为它比两个单独的左右通道更有效。这是因为它能够对两个输入音频通道之间的差异进行编码。 LC3 更高效的设计意味着联合立体声编码与单独编码每个通道然后连接各个编码帧相比几乎没有优势。这种方法允许对两个以上的通道进行编码和组合在一起。

然而，这意味着需要引入一种机制来将多个通道的多个编码帧打包在一起，这是使用通道分配 [BAP 第 4.2 节] 执行的。

图 3.7 显示了一个五声道环绕声系统如何工作的示例。使用 LC3 分别对五个音频输入通道进行编码，然后将编码帧排列成一个媒体包，该媒体包作为单个同步 PDU 传输。 LC3 编解码器帧始终按照与每个音频通道关联的已发布音频能力音频位置的升序排列，使用表 3.2 中汇总的分配编号。因此，在这种情况下，它们将被排序为左前 (0x0000000001)、右前 (0x0000000002)、前中 (0x0000000004)、左后 (0x0000000010) 和右后 (0x0000000020)。

媒体包仅包含编码的音频帧。它可以扩展为包含多个编码音频帧块，每个块包含一个用于每个音频位置的帧，如图 3.8 所示。 CF_N1 指的是来自每个传入音频通道的第一个样本的帧； CF_N2 到那些来自这些音频通道的下一次采样。

使用块可能看起来很有效，但它带有一些重要的警告。它导致更大的数据包，更容易受到干扰。它还增加了延迟，因为controller需要等待多个帧被采样才能开始传输。如果将多个块添加到 Burst Number 或 Pre-Transmission Offset 的多个同步通道功能（我们将在下一章中介绍），它很快就会导致可能达到数百毫秒的延迟。在某些情况下这可能有用，但在我们今天使用的一般音频应用程序中却没有。

没有与媒体包相关的报头信息。相反，可以支持的音频通道数在 Audio_Channel_Location LTV 中指定，该 LTV 包含在 PAC 记录中的 Codec Specific Capabilities LTV 中，每个 Isochronous Stream 的值由 Initiator 在流配置过程中设置。使用的块数同时使用 Codec_Frame_Blocks_Per_SDU LTV 结构进行配置。

我们将在第 5 章讨论 LC3 和服务质量时更详细地讨论这些内容。

3.8呼叫控制ID-CCID

在低功耗蓝牙音频中分离控制平面和数据平面的结果是，内容控制信号（例如电话控制或媒体控制）与音频流之间不再有任何直接关系。这增加了蓝牙 LE audio的灵活性，但会导致更多的复杂性。一个 Initiator 可能有多个同时运行的应用程序，其中用户可能希望将控制与这些应用程序中的特定应用程序相关联。考虑两个单独的电话呼叫的情况，例如蜂窝呼叫和并发 Teams 会议，用户可能希望保留一个呼叫或终止一个呼叫，同时保留另一个呼叫。为了应对这种情况，引入了内容控制 ID，它将内容控制服务实例与特定的单播或广播流相关联。

CCID 可用于广播的说法可能看起来自相矛盾，但它强调了一个事实，即尽管广播流不需要 ACL 连接，但在许多应用程序中都可能存在这样一个事实。例如，如果您从使用单播在手机上收听音乐流转换为广播，以便与朋友分享，您仍然希望能够控制媒体播放器。在这种情况下，您将保持 ACL 链接处于活动状态并将媒体控件与广播流相关联。

内容控制 ID 特征在 GATT spec补充 18 的第 3.45 节中定义为具有唯一标识服务实例的值，该服务实例控制或提供有关音频相关功能的状态信息。它是一个单字节整数，为设备上的所有内容控制服务实例提供唯一标识符。

当音频流包含由内容控制服务控制的内容时，它会将 CCID 包含在音频流metadata中此类服务的列表中，以告诉Acceptor和commander他们可以在哪里找到正确的服务。我们稍后会在第 3.12 节中介绍commander。

CCID 目前仅用于电话承载服务和媒体控制服务。它们不适用于渲染或捕获控制。

3.9 Coordinated Sets (协调集)

尽管我们只拥有它们几年，但我们已经对 TWS 耳塞的概念如此熟悉，以至于大多数人忘记了蓝牙经典音频spec并未涵盖它们的工作方式。如第 1 章所述，它们都依赖于硅芯片公司的专有扩展。 Isochronous Channels 的设计纠正了这一点，允许 Initiator 向多个 Acceptor 发送单独的音频流，以及一个公共参考点，所有 Acceptor 都知道他们已经接收到音频数据并可以开始对其进行解码。然而，蓝牙 LE audio的灵活性，包括来自广播的新用例，提出了一种将接受器作为设备集链接在一起的方法，这些设备可以被视为一个单一的实体。

Coordinated Set 的概念解决了需要。它允许设备公开这样一个事实，即它们是一组设备的一部分，这些设备共同支持一个常见的用例，并且应该作为一个实体进行操作。虽然大多数人会立即想到一对耳塞或助听器，但该组同样可以是一对扬声器或一组环绕声扬声器。一组协调的耳塞应表示为单个设备，以便发生在一个设备上的任何事情都会发生在另一个设备上，尽管如何发生取决于实施。当您调整一对耳塞的音量时，两者的音量应该同时改变 19，如果您决定收听不同的音频源，这种改变应该同时发生在左右耳塞上。您不希望左耳塞在听电视，而右耳塞从手机流式传输音乐的用户体验。

协调由协调集标识profile和服务（CSIP 和 CSIS）处理，它们在 CAP 中引用。 CSIS 和 CSIP 的主要特点，除了将设备识别为协调集的成员外，还提供了锁定功能。这确保了当Initiator与其中一个成员交互时，其他Initiator可以被锁定，从而防止任何其他Initiator与该集合的其他成员交互。

对这种锁的需求是耳戴式设备（例如助听器和耳塞）在使用蓝牙技术直接相互通信时存在问题。这是因为人头非常擅长衰减 2.4GHz 信号。如果耳塞很小，这意味着它的天线也很小，那么一只耳朵中的设备的传输不太可能被另一只耳朵中的伙伴接收。许多当前的耳塞通过在耳塞中包含不同的低频无线电来解决此限制，用于耳对耳通信，通常使用近场磁感应 (NFMI)，头部不会显着衰减。这第二个无线电增加了成本并占用了空间，但移除它并依赖耳塞之间的 2.4GHz 蓝牙链接会增加不同Initiator向左右耳塞发送冲突命令的风险。

使用 CSIP 和 CSIS，如果您在左耳塞上接听电话，发起方会在两个耳塞上设置锁定，并在释放锁定之前将您的右耳塞转换到同一流。锁定功能允许管理这些交互，而无需协调集的成员相互交谈。

如果协调集的成员确实有另一个可以穿透头部的无线电连接，则听力访问服务具有一个功能，该功能将发出信号，表明该无线电可用于将信息传递给另一个助听器。目前此功能仅限于预设设置信息，但将来可能会用于其他功能。

通常，协调集的成员在制造时配置并成对发货，但成员资格可以设置为写入和读取，允许以后配置，或更换有故障或丢失的单元。

3.10 Presentation Delay and serialisation of audio data

支持两个耳塞给我们带来了蓝牙 LE audio必须解决的另一个问题，即确保左右耳的声音完全相同地呈现。过去，音频数据被发送到单个设备，该设备知道如何提取左右信号并同时渲染它们。借助蓝牙 LE audio，CIS 使用不同的传输槽将数据串行发送到不同的目的地。尽管传入的音频通道在同一时间点向Initiator呈现数据，但编码的数据包一个接一个地到达Acceptor。它们可能会因重传而进一步延迟。图 3.9 通过在图 3.6 的 CIG 图上添加左右数据包到两个acceptor的示例来说明这一点

这种序列化会导致问题。人类头脑非常擅长检测左右耳之间声音到达时间的差异，并使用该差异来估计声音的传来方向。

图 3.10 说明，如果您距离音频源 2 米，并且您将头部旋转 10 度，这相当于声音到达时间的差异刚刚超过 70 µs。如果您的左耳和右耳之间的渲染时间存在差异，您的大脑会将其解释为声源移动。如果该差异远大于 25 微秒并且有规律地变化，您就会开始得到一种令人不快的效果，感觉好像声音在您的脑海中四处移动。为了防止这种情况发生，重要的是要有一种同步技术，以确保左右耳塞总是在完全相同的时间呈现各自的音频数据。

我们不能依赖两个耳塞之间的任何蓝牙通信。正如我们之前所说，人头在衰减 2.4GHz 信号方面非常有效，因为它含有大量的水。如果您有小巧的耳塞，可以整齐地放入耳道，则无法保证它们能够相互交流。

蓝牙 LE audio解决方案有两个部分。首先，两个耳塞都需要知道一个共同的同步点，即每个 Acceptor 可以保证每个其他 Acceptor 都有机会接收传输数据包的时间点，无论是单播还是广播流。这个时间点必须由Initiator提供，因为它是唯一知道向所有Acceptor发送数据包需要多少次尝试的设备。 （请记住，Acceptor 通常不能相互交谈，并且可能不知道彼此的存在。）

在大多数情况下，Acceptor 将比公共同步点更早地接收到它们的音频数据包，因为在音频应用程序中，数据包被安排多次重传以最大化接收机会。这是因为丢失数据包导致音频流丢失的问题。这些对于收听者来说是特别烦人的伪影，因此使用重传来帮助提高信号的鲁棒性。这意味着每个acceptor都需要包含足够的缓冲来存储从最早到达时间的数据包——数据包第一次传输的时间，直到公共同步点。我们将在第 4 章了解更多关于同步点的信息。

但是，您无法在同步点渲染音频，因为它仍处于编码状态。在同步点和最终渲染点之间，需要对数据进行解码，并执行任何额外的音频处理，例如丢包隐藏 20 (PLC)、主动降噪 (ANC) 或助听器音频调整，然后才能最终完成呈现。

所需的时间可能因不同的Acceptor而异。虽然您希望一对由一个制造商提供的助听器、扬声器或耳塞设计为每个耳塞具有相同的处理时间，但如果acceptor来自不同的制造商，或者即使固件更新，它可能会有所不同适用于其中一个，但不适用于另一个。出于这个原因，蓝牙 LE audiospec包含了Presentation Delay的概念。 Presentation Delay 是一个 Initiator 定义的值，它指定在每个 Acceptor 中呈现音频的同步点之后的时间（以微秒为单位）。如图 3.11 所示。 SDU 同步点的“C>P”后缀是指 Central 到 Peripheral 的方向（Initiator to Acceptor）。 LL 指的是controller中的链路层，它是接收通过空中发送的数据的地方。

渲染的Presentation Delay还可以包括一个依赖于host应用程序的元素，以故意增加直到渲染的时间。这是链接到视频的音频流的常用技术，可用于延迟渲染点以补偿口型同步问题。在公共广播应用中，可能有多个广播发射器覆盖大型礼堂或体育场，Presentation Delay 也可用于设置特定延迟，以补偿服务于每个观众组的广播发射器与音频源之间的不同距离。声音每秒传播 343m，因此声音在大型体育场内传播可能需要半秒钟。出于这个原因，场地经常对扬声器施加延迟，以帮助同步场地不同部分的声音。使用带有多个蓝牙 LE audio广播发射器的 Presentation Delay 可以实现相同的效果，使观众更接近声音的来源。

每个acceptor都包含它可以支持的最小和最大Presentation Delay值。最小值表示它可以在呈现声音之前对接收到的编解码器数据包进行解码并执行任何音频处理的最短时间；最大值反映了它可以添加的最长缓冲量。这些在配置期间由initiator读取，它必须遵守它正在传输的每个流中所有acceptor的最大值和最小值。这意味着它不能设置大于任何 Acceptor 的最低 Presentation_Delay_Max 值，或低于任何 Acceptor 的最高 Presentation_Delay_Min 的值。 Acceptor 也可以公开他们的 Presentation Delay 首选值，Initiator 应该尝试使用该值，除非 Initiator 上的应用程序设置了特定值，因为它可能用于实时应用程序或补偿口型同步。预计 Presentation Delay 不会暴露给接收音频的设备用户，因为它始终由应用程序在 Initiator 上设置。

Presentation Delay 旨在为多个 Acceptor 提供一个公共渲染点。它支持Acceptor可能不知道彼此存在的情况，例如一个耳朵有听力损失的用户，他会佩戴助听器和一个耳塞。由于相同的 Presentation Delay 应用于两者，因此两个设备将同时呈现。在大多数应用中，Presentation Delay 的值应尽可能小。支持较高的 Presentation Delay 值会增加 Acceptor 资源的负担，因为它需要将解码的音频流缓冲更长时间。

对于Broadcast，当Initiator 和Acceptor 之间没有连接时，Initiator 需要仅根据其应用来判断所有潜在Broadcast Sink 可接受的Presentation Delay 的值。一般来说，应该避免超过 40ms（每个 Acceptor 必须支持）的值，因为如果环境声音也存在，它们可能会引入回声，除非它们专门用于在非常大的场所中适应这种情况。如果 Presentation Delay 超出它可以支持的范围，spec没有定义广播接收器应该做什么。

对于单播和广播，顶层profile可以为 Presentation Delay 指定一个特定值，特别是如果它们支持低延迟应用程序。例如，如果音频流也存在环境声音，他们可能需要使用“实时”Context类型，以及不超过 20 毫秒的Presentation Delay设置（用于 HAP 或 TMAP 支持）。

Presentation Delay 也适用于音频捕获，其中音频数据从 Acceptor 传输到 Initiator（在spec中表示为 P>C，或 Peripheral 到 Central）。在这里，它表示从音频被捕获、随后进行处理、采样和编码的点到可以传输第一个等时流的第一个数据包的参考点的时间，如图 3.12 所示。

在音频捕获中使用 Presentation Delay 可确保每个麦克风或其他音频转换器在完全相同的时间点捕获声音。它定义了一个间隔，在此期间每个acceptor都可以准备其音频数据包以进行传输，第一次传输发生在Presentation Delay结束时。然后所有其他音频数据源将在其分配的传输时隙中传输其编码数据包。当手机想要组合来自左右耳塞的麦克风数据时，这是可取的，因为它可以使用常见捕获时间的知识来组合它们。Initiator通常不会使用基于捕获时间的简单混合，而是使用此知识来通知数字拼接技术，以在运行噪声消除算法之前对齐多个流，但这超出了蓝牙spec。

虽然在单播音频源中捕获最常见的Presentation Delay是在每个耳塞或助听器中使用一个麦克风的情况，但它同样适用于具有多个麦克风的单个设备。这包括立体声麦克风和立体声耳机，每个罐头都有麦克风。在这些设备中，实现可以使用通道分配将两个麦克风信号编码到单个编解码器帧中以进行多路复用（请参阅下面的第 3.7 节），或者使用Presentation Delay单独传输它们以确保捕获对齐。在这两种情况下，都需要设置 Presentation Delay 的值以涵盖音频处理和编码时间。

在麦克风间隔更远的地方，接收到的数据将不会反映它们位置之间的音频路径差异。如果要恢复该信息，发起方可能需要调整传入的流。

重要的是要理解，Presentation Delay 仅适用于 Acceptor，无论它是充当音频接收器还是音频源。在许多情况下，Acceptor 将同时充当两者。通常，Presentation Delay 的值对于每个方向都是不同的，以应对编码音频数据比解码需要更长的时间这一事实。我们将在第 4 章中更详细地研究如何使用Presentation Delay来影响延迟和鲁棒性。

3.11 Announcements

作为为Acceptor提供更多自主权的理念的一部分，蓝牙 LE audio spec允许他们使用服务数据 AD 类型来传输通知，通知Initiator他们可以接收或传输音频数据。 Acceptor 可以决定是使用 Targeted Announcement，它是可连接的并请求连接，还是使用 General Announcement，它只是说它可用，但不启动特定连接。公告的 AD 类型字段中使用的 LTV 结构如下表 3.3 所示。

通用音频profile (CAP) 通过定义两种特定模式来描述Initiator或commander（见下文第 3.12 节）如何对公告作出反应，这有助于解释何时使用每种模式。这些是：

• INAP - 音频相关外设模式 (INAP) 的即时需求，以及

• RAP – 准备好音频相关的外围模式 (RAP)。

INAP 是指 Initiator 或 Commander 想要建立连接的情况，通常是由于用户操作，并且需要确定哪些 Acceptor 可用于连接。如果它发现了一个可用的 Acceptor，它应该连接，或者，如果它发现了多个，则向用户提供一系列可用的 Acceptor，让他们做出选择。在 INAP 模式下运行时，Initiator 或 Commander 通常会以更高的速率开始扫描以查找 Acceptor。

相反，在 RAP 模式下，Initiator 以较低的速率扫描，但会通过连接响应来自 Acceptor 的 Targeted Announcement。

Acceptor应仅在需要立即连接时在有限的时间内使用定向公告。

Announcements 中还有一个更微妙的地方，即它们可能包含也可能不包含 Context Type 值。如果它们与音频流相关使用，则应包含它，称为 BAP 公告 [BAP 3.5.3]，其中包含可用音频Context字段。如果它们用于控制目的或扫描委派，则不会。然后将它们称为 CAP 公告 [CAP 8.1.1]

广播者在他们的扩展广告中使用公告来通知广播接收器和广播助手（参见第 3.12 节）他们有可用的广播流。它们有两种形式：

3.11.1 Broadcast Audio Announcements

广播音频公告通知任何扫描设备广播者正在传输一组一个或多个广播音频流。用于广播音频公告的 LTV 结构如下表 3.4 所示。

3.11.2 Basic Audio Announcement

广播源在周期性广告序列中使用了令人困惑的类似标题的基本音频公告，以通过广播音频流端点结构 (BASE) 公开广播音频流参数。第 8 章描述了它的使用。

3.12 Remote controls (Commanders)

蓝牙一直是遥控设备的好选择，但这些几乎都是简单的远程遥控，本质上是传统红外远程遥控的蓝牙替代品。助听器和耳塞使远程遥控成为一个有吸引力的选择，因为这些设备非常小，以至于它们没有空间容纳许多按钮，即使在它们有的地方，也可以操纵一个你看不到的按钮（因为它位于你的头或耳后）是糟糕的用户体验。由于大多数耳塞与手机、笔记本电脑或 PC 一起使用，并且生成音频流的应用程序通常包含用于暂停、接听电话或更改音量的控件，因此这不是主要问题。然而，助听器用户在使用助听器放大环境声音时也需要控制其音量。

为了比在助听器上摸索按钮更容易，业界开发了简单的、类似钥匙扣的远程遥控，允许用户轻松调节音量或更改音频处理算法以适应他们的环境（这些被称为预设设置）。即使助听器包含蓝牙技术，大多数时候用户也不会启用活动的蓝牙链接，并且将手机从口袋或包中取出，然后找到合适的应用程序是调节音量的不方便方法。如果您被嘈杂的噪音所困扰，则可以更快更轻松地取出助听器，这不是良好的用户体验。

这只是问题的开始。蓝牙 LE audio的新广播功能将带来更多的公共基础设施，用户需要在其中导航多个不同的广播并决定接收哪个广播。这不仅在助听器或耳塞上很难做到，而且涉及到相对耗电的扫描。为了解决这些问题，开发了单独设备的概念，它可以提供音量控制、发现和显示可用的广播源、发现加密广播的密钥，并允许助听器用户更改他们的预设。也可以用它来接听电话或控制媒体播放器。这些设备具有 CAP 中定义的 Commander 角色，但也可以使用 BAP 中的 Broadcast Assistant 角色来发现广播以及作为内容控制client。大多数顶层profile为这些设备可以承担的其他角色引入了更多名称。对于文档的其余部分，我将使用commander术语，除非它用于广播助手的特定子集。

Commander 是蓝牙拓扑的重要新增功能。该角色可以在电话上实现，既可以作为独立应用程序，也可以作为电话或音频流应用程序的一部分。它也可以在任何与acceptor或acceptor协调集有蓝牙连接的设备中实现。这意味着您可以在专用远程遥控、智能手表、腕带甚至助听器和耳塞的电池盒中实现它。commander可以有一个显示器来显示有关广播的文本信息，以帮助您选择它们，或者只是音量按钮。commander以先到先得的方式工作，因此您可以拥有多个commander，当您想要改变音量或将助听器静音时，您可以使用先到手的commander。因为所有的功能都是明确指定的，这也意味着多个设备可以互操作地实现它们。在第 12 章中，我们将研究它们可能会改变我们使用蓝牙音频设备的方式的一些方式。

-oOo-

在介绍了这些新概念之后，我们现在可以深入研究spec，了解它们是如何工作的，以及它们如何为蓝牙 LE audio启用新的用例。