机器翻译，仅用于学习记录，原文链接
为了向设计人员提供他们需要的灵活性，新的蓝牙 LE 音频规范引入了一些重要的新概 念。在本章中，我们将了解它们的作用以及为什么需要它们。由于这些功能已紧密集成到规范中，因此当我们深入研究 BluetoothCore 规范和 GAF 的细节时，下面的一些描述将变得更加清晰。但是，在这个阶段介绍它们是有用的，因为它们渗透到后面的大部分内容中。
3.1 Multi-Profile设计
正如我们所看到的，蓝牙经典音频面临的挑战之一是多配置文件问题，用户在流式传输音乐、拨打电话和使用语音识别之间切换。随着音频用例的复杂性不断增加，这个问题不会改善。两个成功的经典蓝牙音频配置文件 – 免提配置文件 （HFP） 和音乐流 （A2DP）是在假设用户使用其中一种，在从电话转向音乐时开始新的独立会话时设计的。很快就发现，这些不是独立的功能，但手机用户会期望一个用例会打断另一个用例。多年来，该行业已经制定了解决此问题的规则和方法，最终在 2013 年发布了多配置文件规范（MPS），该规范实质上收集了这些配置文件之间常见转换的规则集。
Multi Profile 规范不是特别灵活，也没有预见到新用例的出现，例如语音识别、语音助手和 GPS 卫星导航中断。基本规范也不是特别通用。尽管 HFP 已经经历了多个版本，并产生了大约 20 个互补规范，解决了汽车与手机交互的特定方面，但它仍然难以跟上非蜂窝 VoIP 电话应用的步伐。它和 A2DP 都没有充分解决音频不断变化的性质，用户在一天中连接到多个不同的音频源，并且还可能拥有多个不同的耳机和耳塞。
从一开始，Bluetooth LE Audio 的开发理念就是支持“多配置文件设计”。它认识到用户可能有多个耳机和音频源，并且会以临时方式不断更改连接。广播音频的添加使这一点变得更加重要，因为预计广播在场馆、商店、休闲设施和旅行中的普及将增加用户每天可能建立的不同连接的数量。显然，提供工具以实现无缝的用户体验非常重要。
3.2 Audio Sink 引领的旅程
除了这些要求之外，人们还意识到手机不一定会成为音频世界的中心，这在整个发展过程中一直是一个默认的假设这一直是 Bluetooth Classic Audio 规范发展过程中的一个默认假设。随着越来越多的不同音频源可用，考虑用户在一天中如何连接耳塞或助听器非常重要。这颠覆了以手机为中心的音频世界的感知观点，取而代之的是 Audio Sinkled 旅程的概念。
在这种方法中，手机不再是您收听内容的仲裁者。相反，它假设用户越来越有可能整天佩戴一副助听器或耳塞，不断改变他们的音频源。它可能从闹钟开始，然后让你的语音助手打开你的收音机，在公交车站等车时的旅行更新，电脑的语音控制，接电话，门铃打断，回家后在电视机前放松，直到微波炉告诉你你的晚餐准备好了。这种关于谁在控制的概念上的转变在很大程度上借鉴了助听器佩戴者的经验，他们通常在一天中的大部分时间都佩戴助听器。在那段时间的大部分时间里，助听器在没有任何蓝牙连接的情况下工作，只是倾听和加强佩戴者周围的声音。但是佩戴者可以将其连接到大量的基础设施音频源 - 超市收银机、公共交通信息、剧院和礼堂和电视，以及电话和音乐播放器（如果它们支持蓝牙经典音频）。一旦它广泛可用，更多的消费者可能会使用此功能。
当然，手机仍将是音频的主要来源，但 PC、笔记本电脑、电视、平板电脑、Hi-Fi 和语音助手也将越来越多地成为音频来源。从门铃到烤箱的一系列智能家居设备也加入了他们的行列。与此同时，消费者正在购买更多的耳机。拥有一对睡眠耳塞、一副耳塞、一副立体声耳机和一个条形音箱或蓝牙扬声器的情况并不少见。随着潜在组合的增加，用户界面能够容纳这些不同的连接以及它们之间的过渡至关重要。
3.3 术语
蓝牙 LE Audio 规范的不同部分对发送和接收设备及其功能使用不同的名称。每个规范都将它们称为角色，因此当我们从 BluetoothCore 规范转变为顶级配置文件时，我们将为每个设备积累至少四个不同的角色。这是有充分理由的，因为堆栈的每一级都会在这些 Role 中产生更多的特异性，从而使设备可以实现特定的组合来实现目标功能。但它们可能会让人感到困惑。
BluetoothCore 规范是指中央设备和外围设备，其中中央设备发送命令，外围设备响应。在BAP 中，它们称为 Client （客户端） 和 Server （服务器） 角色。向上移动一层，CAP将它们定义为 Initiator 和 Acceptor 角色。发起方角色存在于中央设备中，负责设置、调度和管理同步流。接收器是参与这些流的设备——通常是助听器、扬声器和耳塞。始终有一个 Initiator，但可以有多个 Acceptor。图 3.1 显示了不同的命名法。
我将在大多数时间使用 Initiator 和 Acceptor 名称（即使它们在技术上是 Role），因为我认为它们最能解释蓝牙 LE Audio 的工作方式。发起方和接收端都可以同时发送和接收音频流，并且它们都可以包含多个蓝牙 LE 音频接收器和源。要记住的重要一点是，Initiator 是执行同步流的配置和调度的设备，而 Acceptor 是接受这些流的设备。该概念适用于单播和广播。在广播中，规范使用术语 Broadcast Source 和 Broadcast Sink来指代角色，但大多数开发人员选择将它们称为 Broadcast Transmitters 和 Broadcast Receivers。由于没有链接允许它们相互影响，因此 transmitter / source 和 receiver/sink 的名称对具有相同的含义，因此在这一点上它们可以互换使用。
在这一点上，值得稍微转移一下，看看蓝牙 LE Audio 中使用的一些术语。这将介绍一些我们还没有讨论过的特性，我们将在第 4 章中详细介绍这些特性，当我们谈到Isochronous Streams 时。
在整个规范中，有许多不同的名称和短语来描述频道和流。它们具有一些非常不同的含义，有时甚至略有不同，具体取决于您正在查看的规范，但我已尝试在图 3.2 中捕获主要含义。
该图显示了音频数据从左到右的概念传输。在最左侧，我们有音频传入，它可以是模拟或数字信号。它显示为 Audio IN。在另一端，我们看到音频在 Audio OUT 处渲染，它可能在扬声器或耳塞上。这两个点的音频称为音频通道（两端是同一个音频通道），相当于MP3 播放器和扬声器之间的有线连接所承载的音频。音频通道在 BAP 中定义为音频单向流入蓝牙设备输入端，然后从另一端流出。（在实践中，该 “out” 通常会直接进入您的耳机换能器或扬声器。或者它可以在进一步的处理阶段保持数字化。Audio Channel 的输入和输出的详细信息特定于实现，不在 Bluetooth 规范范围内。音频是什么以及无线传输和解码后如何处理音频不在规范的范围内。
如何将音频输入传送到音频输出是蓝牙规范中定义的内容。它由图 3.2 中的虚线框表示。
音频使用新的 LC3 编解码器进行编码和解码，除非实现需要使用特定的附加编解码器。可以使用其他编解码器，但所有设备都必须支持一些基本的 LC3 配置，这些配置在 BAP 中定义，以确保互作性。编码器生成编码的音频数据，这些数据进入 Isochronous Streams的有效负载。
音频数据编码后，它被放入 SDU（服务数据单元）中，BluetoothCore 规范将其转换为PDU（协议数据单元），这些 PDU 使用同步通道传输到接收设备。收到 PDU 后，它将被重建为 SDU 以交付给解码器。同步流是用于描述封装在 PDU 中的 SDU 从编码器输出到解码器输入的传输的术语。它包括重新传输和同步多个同步流所需的任何缓冲。通过同步流的编码音频数据流在 BAP 中定义为音频流，并且与音频通道一样，始终是单向的。图 3.3说明了不同项的关系。
BluetoothCore 规范将服务于同一应用程序的同步流一起放入一个同步组中。对于单播流，它称为连接的同步组 （CIG），其中包含一个或多个连接的同步流 （CIS）。对于Broadcast，它是一个广播同步组 （BIG）。如果一个 Isochronous Group 中存在多个Isochronous Stream，并且沿同一方向传输音频数据，则 Isochronous Streams 在应用程序层应彼此具有时间关系。时间关系是指预期同时渲染或捕获的音频通道。一个典型的应用程序是立体声流的左右组件在两个单独的耳塞中呈现。这突出了一个事实，即 CIG 或BIG 可以包含流向多个设备的同步流。
蓝牙 LE Audio 的设计非常灵活，这意味着有时有不同的做事方式。举个例子，如果我们看一下从手机到耳机的简单连接，我们需要一个音频流向每个方向。一种方法是为每个方向建立单独的 CIS。
在图 3.4 中，我们可以看到两个 CIS，一个传出 （CIS 0） 和一个传入 （CIS 1），都包含在同一个 CIG 中。我们可以通过使用单个 CIS 来优化这一点，如图 3.5 所示，它显示了单个双向 CIS （CIS 0），在同一个 CIG 中双向传输音频数据。我们将在下一章中确切地看到它是如何工作的。
这两个选项都是允许的;由应用程序决定哪个最适合其使用。在大多数情况下，双向优化将是首选选项，因为它可以节省通话时间。
图 3.6 显示了一个典型的应用，其中 CIG 包含两个 CIS，它们可能会将手机连接到一对耳塞，但返送麦克风仅在其中一个耳塞中实现。它显示 CIS 0，这是一个双向 CIS，将音频从电话通话传出到耳塞，并将音频从耳塞的麦克风传回手机。CIS 1 将音频流从手机传输到另一个耳塞。由应用程序来确定它是正在发送的立体声流还是单声道。在后一种情况下，相同的单声道音频数据通过 CIS 0 和 CIS 1 分别发送到两个耳塞。这里需要注意的重要一点是，一个 CIG 可以提供多个 Acceptor，为每个 Acceptor 提供不同的音频数据。
3.4 上下文类型
要决定要连接到哪些音频流，设备需要更多地了解这些流包含的内容或它们的用途。引入了上下文类型来描述与音频流关联的当前用例或用例。它们的值在通用音频的 Bluetooth Assigned Numbers 文档中定义。上下文发起方和接受方都可以使用上下文类型来指示他们想要参与的活动或连接类型，并且适用于单播和广播。
使用 Bluetooth Classic Audio 配置文件时，中央设备和外围设备之间的对话基本上是“我想建立音频连接”，没有关于它是什么的更多信息。由于 HFP 和 A2DP 配置文件本质上是单一用途的配置文件，这不是问题，但在蓝牙 LE 音频中，音频流可用于铃声、语音识别、播放音乐、提供卫星导航指令或许多其他应用程序，因此更多地了解请求流的预期原因很有用。这就是 Context Types 的用武之地。
正如我们稍后将看到的，Context Types 在单播流配置过程中用作可选元数据。Acceptor可以在任何时间点公开它准备接受的 Context Types。例如，如果助听器佩戴者正在进行个人（非蓝牙）对话，他们不想被电话打断，他们可以将助听器设置为对与 “铃声” 上下文类型关联的流不可用。这意味着助听器会静默拒绝来电。这比将手机静音更通用，因为通过使用上下文类型，他们将拒绝来自他们连接的任何电话的来电，或来自任何其他连接设备的 VoIP 呼叫。他们还可以在通话中设置 “铃声”上下文类型，以防止任何其他通话打断当前通话。这可以基于每个设备完成，这意味着您可以允许对一部特定电话的来电，同时阻止另一部电话，从而为 Acceptor 提供一种强大的方法来控制哪些设备可以请求音频流。
发起方在尝试建立音频流时使用上下文类型，并将关联的用例通知接受方。如果该Context Type 在 Acceptor 上设置为不可用，则配置和流建立过程将终止。这发生在设置同步流之前的 ACL 链路上，这意味着这些决策可以与现有音频流并行进行，而不会干扰它，无论请求是来自当前提供流的设备，还是来自想要建立或替换现有流的其他发起方。
现有的音频流是单播还是广播并不重要，这意味着使用广播音频流收听电视的助听器用户可以使用上下文类型来防止他们的当前流被任何电话打扰。
目前，Generic Audio Assigned Numbers 文档中定义了 12 种 Context Type，它们显示在 Context Types 的两个八位字节位域中，如表 3.1 所示，每个位代表一个 Context Type。这允许在任何时候使用多个值。
|
Bit
| Context Type | Description |
| 0 | Unspecified | Any type of audio use case which is not explicitly supported by another Context Type on a device. |
| 1 |
Conversational
|
Conversation between humans, typically voice calls,
which can be of any form, e.g., landline, cellular, VoIP,
PTT, etc.
|
| 2 | Medi |
Audio content. Typically, this is one way, such as radio,
TV or music playback. It is the same type of content as
is handled by A2DP.
|
|
3
| Game |
Audio associated with gaming, which may be a mix of
sound effects, music, and conversation, normally with
low latency demands.
|
|
4
| Instructional |
Instructional information, such as satnav directions,
announcements or user guidance, which often have a
higher priority than other use cases
|
|
5
| Voice assistants |
Man-machine communication and voice recognition,
other than what is covered by instructional. It is implied
that this is in the form of speech.
|
|
6
| Live |
Live audio, where both the Bluetooth Audio Stream and
the ambient sound is likely to be perceived at the same
time, implying latency constraints.
|
| 7 | Sound effects |
Sounds such as keyboard clicks, touch feedback and
other application specific sounds.
|
| 8 | Notifications |
Attention seeking sounds, such as announcing the arrival
of a message.
|
| 9 | Ringtone |
Notification of an incoming call in the form of an
inband audio stream. The Ringtone Context Type is not
applied to an out of band ringtone, which is signalled
using CCP and TBS.
|
| 10 | Alerts |
Machine generated notifications of events. These may
range from critical battery alerts, doorbells, stopwatch
and clock alarms to an alert about the completion of a
cycle from a kitchen appliance or white goods.
|
| 11 | Emergency alarm | A high priority alarm, such as a smoke or fire alarm. |
| 12 - 15 | RFU |
Not yet allocated.
|
其中大多数是显而易见的，但其中两种上下文类型值得特别注意： “铃声”和“未指定”。
“铃声”上下文类型用于宣布来电，但仅限于存在需要设置音频流的带内铃声的情况。如果用户已经从其他设备接收音频流，而不是从有来电的设备接收音频流，则可能会出现问题。要在不丢弃当前音频流的情况下向用户发出来电信号，至少需要一个耳塞设置与第二个发起方的单独单播流。在实践中，许多 Acceptor 不太可能拥有同时支持来自不同Initiator 的并发流的资源。接受者可以丢弃当前音频流以切换到带内铃声，但如果他们随后拒绝呼叫，则需要恢复原始音频流。在大多数情况下，提供带外铃声可能会带来更好的用户体验，该铃声由耳塞使用 CCP 和 TBS 生成。用户可以在现有音频输出中听到此声音，并决定是接受还是拒绝呼叫。如果他们拒绝了呼叫，他们可以继续收听其原始流。在大多数情况下，«铃声» 最适合用于管理是否允许设备通过来电中断当前音频应用程序。我们将在第 9 章中介绍如何处理带外铃声。
“未指定”上下文类型是一个包罗万象的类别。每个 Acceptor 都必须支持 “未指定”上下文类型，但不需要使其可用。当 Acceptor 将 “未指定” 上下文类型设置为available 时，它表示它将接受除它明确表示不支持的上下文类型以外的任何上下文类型。随着实现者习惯了上下文类型，一些实现者将使用它来允许 Central 设备（通常是电话）负责音频用例，其方式与 A2DP 和 HFP 大致相同。仅将 “Unspecified” 设置为available 的 Acceptor 实际上允许手机完全控制它可以发送的内容。我们将在第 7 章中更详细地讨论 Supported 和 Available 的概念。
所有 Context Types 都是彼此独立的。使用它们中的任何一个并不意味着或需要支持另一个，除非该要求是由顶级配置文件施加的。例如，对 “铃声” 上下文类型的支持通常并不意味着或需要对 “对话” 上下文类型的支持，因为 “铃声” 本身可以用作分机铃声，以提醒听力损失的人固定电话的来电。
Context Types 由 Initiator 和 Acceptor 用于提供有关用例，允许他们决定是否接受流。为了实现这一点，它们被用于一系列特征和LTVmetadata 结构中。您将在以下位置找到它们以这种方式使用：
- Supported_Audio_Contexts特性 [PACS 3.6]
- Available_Audio_Contexts特性[PACS 3.5]（也用于服务器公告 – [BAP 3.5.3]）
- 首选音频上下文 LTV 结构（PAC记录中的元数据）（另见 [BAP 4.3.3]）
- 流式音频上下文 LTV 结构（发起方用于标记音频流的元数据）[BAP 5.6.3、5.6.4、 3.7.2.2]
3.5 未连接的模型
在经典蓝牙中，音频应用已经发展出一种常见的连接模式，其中 Central 设备建立连接，然后尽可能长时间地保持连接，无论它是否使用它。这种方法的优点是，当事件发生时，例如来电到达，与耳塞的连接已经存在，因此耳塞中的铃声几乎可以立即出现。这种行为的起源可以追溯到蓝牙的早期，当时人们认为大多数人主要将其用于手机和耳机，以便它们之间的连接可以持久。为了降低保持链路活动所需的功率，已经做了大量工作，从而产生了 sniff 模式和最近的 sniff 子评级。但两者都适用于持久连接。虽然它解决了一个问题，即新连接的延迟，但它导致了其他几个问题，这些问题一直是蓝牙音频体验的持续问题。
第一个是它假设用户有一部手机和一副耳塞。一旦他们获得第二个耳机，Central 就需要求助于“设备选择器”或“选择列表”应用程序来更改他们正在使用的内容。当呼叫通过其他设备（例如笔记本电脑或第二部电话）打入时，第一个 Central 可能不愿意放弃控制权，从而导致一些意想不到的行为。添加不同的应用程序，例如在一台设备上的音乐之间切换到另一台设备上的电话，会导致众所周知的多配置文件问题。为了使这些用例中最常见的工作发挥作用，已经投入了大量工作，但由于消费者希望将越来越多的蓝牙设备用于越来越复杂的用例，因此它不容易扩展。
Bluetooth LE Audio 的目标之一是尝试通过设计消除多配置文件问题，这需要对连接模式进行许多根本性的更改。我们刚刚看到的第一个变化是 Context Types 提供有关 Audio Stream 用例的信息。第二个是对连接模型的根本性改变，从经典的“始终连接”模型转向新的未连接模型，在这种模型中，设备可以宣布它们可以参与用例。这允许更大的灵活性。他们可能仍然保留 ACL 连接，但可以在不需要时丢弃同步流，因为他们知道他们可以在需要时使用相同的设备或其他设备快速建立新的连接。
3.6 可用性
为了使设备能够对它们正在做什么做出明智的选择，它们不仅需要能够告诉彼此他们正在参与的用例（这就是 Context Types 的原因），还需要能够随着当前用例的变化，他们有兴趣参与哪些未来的用例。这就是 Availability 的用武之地。
正如我们在上面看到的，Acceptor 使用 Context Types 来表示它们是否可以参与用例。
这可以通过两种方式实现。Acceptor 使用 PACS 中定义的 Available_Audio_Contexts 特性来说明当前可以使用哪些支持的音频上下文类型来建立音频流。音频源（无论是发起方还是接受方）还在其编解码器配置的元数据中使用 Streaming_Audio_Contexts LTV 结构，以通知音频接收器与音频流关联的用例。
想要建立单播音频流的蓝牙 LE 音频设备还可以通过在其广告 PDU 中包含Streaming_Audio_Contexts LTV 结构，在开始音频流之前使用上下文类型来表示其可用性。以类似的方式，充当广播源的发起方将其包含在其定期通告的元数据部分中，以便广播接收器和广播助理可以从他们不感兴趣的用例中筛选出他们想要的使用案例。
对于广播源，您应该注意，如果 Streaming_Audio_Contexts 字段不存在于编解码器 ID的元数据中（我们将在第 4 章中介绍），它将被解释为意味着唯一的Supported_Audio_Contexts 值是 “未指定”，因此每个广播接收器都可以与它同步，除非它们明确将 “未指定” 设置为不可用。
3.7 公告
新的未连接环境意味着引入了新的流程以允许快速建立连接。其中一个关键部分是 公告的引入。在单播和广播拓扑中，Initiator 和 Acceptor 都使用公告来传达有关使用案例的信息以及设备是否准备好参与使用案例。
Announcements 还支持为单播连接中涉及的 Acceptor 提供更多自主权的理念。蓝牙 LE音频规范允许接受方使用服务数据 AD 类型传输公告，通知发起方他们可以接收或传输音频数据。接受者可以决定是使用 Targeted Announcement（目标公告）还是 General Announcement（一般公告），其中它只是表示它可用，但不启动特定连接。公告可以由多个接受者接收和处理。
3.7.1 单播公告
对于单播用例，Acceptor 可以使用其 ASCS UUID 的 AD Type 字段中使用的 LTV 结构在广告中发送公告，如表 3.2 所示。
公告可以是 General 或 Targeted，具体取决于接受者对用例的要求。公告中还有一个微妙之处，即它们可能会或可能不包括 Context Type 值，该值取决于它们是在 BAP 上下文还是 CAP 上下文中使用。我们将在第 6 章中探讨其中的细节。目前，需要了解的重要一点是，当 Acceptor 没有要发送或接收音频数据时，Announcements 允许 Acceptor 保持未连接状态，但一旦情况发生变化，它们就可以快速建立连接。
3.7.2 广播公告
3.7.2.1 广播音频公告
广播音频通知在 BAP 中定义，并通知任何扫描设备广播源正在传输一组一个或多个广播音频流。用于广播音频公告的 LTV 结构如下面的表 3.3 所示。
3.7.2.2 基本音频公告
在定期广告系列中，广播源使用标题相似且令人困惑的基本音频通知（也在 BAP 中定义），以通过广播音频流终端节点结构 （BASE） 公开广播音频流参数。它的使用在第8章中描述。
3.7.2.3 公开广播公告
PBP 中引入了公共广播公告，以便为扫描广播存在的设备提供更多信息。有关广播的大多数详细信息都包含在 定期通告 中，这是扫描程序将访问的最后一个通告。公共广播公告旨在提供关键有关扩展通告中广播的信息，有效地充当过滤器，以限制扫描程序读取每个定期通告序列 的需求。公共广播公告中包含的信息是允许扫描程序确定广播流是否符合 Auracast™ 传输 的要求，以及它是否加密的信息。公共广播公告的存在可以显著降低广播接收器或 Commander 的扫描要求（请参阅第 3.13 节）。我们将在第 11 章中确切地了解 Public Broadcast Profile 的作用。
3.8 内容控制 ID - CCID
在蓝牙 LE Audio 中将控制平面和数据平面分开的结果是，与当前用例相关的控制信号（例如电话控制或媒体控制）与音频流之间不再有任何直接关系。这增加了蓝牙 LE Audio 的灵活性，但会导致复杂性增加一些。一个 Initiator 可能有多个并发运行的应用程序，用户可能希望将控制权与其中的特定应用程序相关联。考虑两个单独的电话呼叫的情况，例如蜂窝呼叫和并发 Teams 会议，其中用户可能希望将一个呼叫置于保留状态，或者终止一个呼叫同时保留另一个呼叫。为了应对这种情况，引入了内容控制 ID，它将内容控制服务实例与特定的单播或广播流相关联。
CCID 可用于广播的说法似乎自相矛盾，但突出了这样一个事实，即尽管广播流不需要ACL 连接，但许多应用程序可能存在 ACL 连接。例如，如果您从使用单播收听手机上的音乐流过渡到广播，以便您可以与朋友分享，那么您仍然希望能够控制媒体播放器。在这种情况下，您将保持 ACL 链接处于活动状态，并将媒体控件与广播流相关联。
内容控制 ID 特征在 GATT 规范补充的第 3.45 节中定义为具有唯一标识控制或提供音频相关功能状态信息的服务实例的值。它是一个八位字节整数，为设备上的所有内容控制服务实例提供唯一标识符。
当音频流包含由内容控制服务控制的内容时，它会在音频流元数据的此类服务列表中包含CCID，以告知接受者和指挥官他们可以在哪里找到正确的服务。我们稍后会在 3.13 节中介绍指挥官。
CCID 目前仅用于 Telephone Bearer Service 和 Media Control Service。它们不适用于渲染或捕获控制。
3.9 协调集
尽管我们只拥有它们几年，但我们已经非常熟悉 TWS 耳塞的概念，以至于大多数人忘记了蓝牙经典音频规范并未涵盖它们的工作方式。如第 1 章所述，它们都依赖于硅芯片公司的专有扩展。同步通道的设计纠正了这一点，允许 Initiator 将单独的音频流发送到多个Acceptor，以及一个公共参考点，所有 Acceptor 都知道他们已经收到了音频数据并可以开始解码。这意味着 Initiator 需要知道 Acceptor 对（即单独的设备）可以被视为单个实体。
协调集的概念解决了这一需求。它允许设备暴露这样一个事实，即它们是一组设备的一部分，这些设备共同支持一个常见用例，应该作为一个实体进行作。虽然大多数人会立即想到一对耳塞或助听器，但那套同样可以是一对扬声器或一组环绕声扬声器。一组协调的耳塞应该表示为单个设备，这样发生在一个耳塞上的任何事情都会发生在另一个设备上，尽管如何发生可能取决于实现。当您调整一对耳塞的音量时，两个耳塞的音量应该同时变化，如果您决定收听不同的音频源，则左右耳塞应该同时发生这种变化。您不希望出现左耳塞在听电视，而右耳塞在从手机播放音乐的用户体验。
协调由 Coordinated Set Identification Profile and Service（CSIP 和 CSIS）处理，它们在 CAP 中引用。CSIS 和 CSIP 的主要特点除了将设备识别为协调集的成员外，还提供了锁定功能。这可确保当 Initiator 与其中一个成员交互时，可以锁定其他成员，从而防止任何其他 Initiator 与该集的其他成员交互。
需要这种锁的是耳戴式设备（例如助听器和耳塞）在使用蓝牙技术直接相互通信时存在问题。这是因为人类的头部非常擅长衰减 2.4GHz 信号。如果耳塞很小，这意味着它的天线也很小，那么一只耳朵的伴侣不太可能接收到来自一只耳朵中的设备的传输。许多当前的耳塞通过使用一种不会被头部显着衰减的技术（例如近场磁感应 （NFMI））在耳塞内包含一个不同的低频无线电来实现耳对耳通信，从而绕过了这一限制。第二个无线电增加了成本并占用了空间，但移除它并依赖耳塞之间的 2.4GHz 蓝牙链接提高了不同的启动器可能会向左右耳塞发送冲突命令的风险。
使用 CSIP 和 CSIS 时，如果您在左耳塞上接听电话，发起方会在两个耳塞上设置锁定，并在释放锁定之前将您的右耳塞转换为相同的流。Lock （锁定） 功能允许管理这些交互，而无需 Coordinated Set 的成员相互通信。
如果一个协调集的成员确实有另一个可以穿透头部的无线电连接，听力访问服务有一个功能，可以发出信号，表明这个无线电可以用来向另一个助听器传递信息。目前，此功能仅限于有关预设设置的信息，但将来可能会用于其他功能。
通常，协调集的成员在制造时进行配置并成对发货，但成员资格可以设置为写入和读取，以便以后进行配置或更换有故障或丢失的设备。
3.10 音频位置
在以前的每个蓝牙音频规范中，都有一个蓝牙 LE 音频源和一个蓝牙 LE 音频接收器。音频流以单声道或立体声形式发送，由音频接收器来解释它的呈现方式。立体声流通常被编码为联合立体声，解码后，耳塞、助听器或扬声器会丢弃不需要的音频信息。这样做的优点是简单，因为只传输一个流，但它会导致传输冗余信息。
蓝牙 LE Audio 旨在解决具有多个扬声器或耳塞的应用问题，同时支持多种不同的音频流，这些音频流可能具有不同的质量或不同的语言。它能够优化每个 Audio Sink 的通话时间，只需向设备发送所需的音频流。一般来说，对于一对耳塞，左耳塞只接收左侧音频流，右耳塞只接收右侧音频流。这意味着每个 Audio Sink 都可以最大限度地减少其接收器的开启时间，从而降低其功耗。它还提高了稳健性，因为较小的数据包不易受到干扰。
为此，需要对设备进行配置，以了解它们要接收的空间信息，例如，来自立体声输入的左流或右流。它们通过指定音频位置来实现这一点，该位置在 BAP 中定义为“音频通道在扬声器或其他渲染音频的音频换能器的空间布置中的预期逻辑空间渲染位置”。实际上，它是对设备是什么的声明，例如左耳塞或右扬声器。
事实证明，Audio 位置的概念非常令人困惑。在大多数情况下，配置为 Front Right 的设备始终希望接收正确的立体声信号流。对于单播应用程序，这是因为耳塞将通知这是因为耳塞将通知 Initiator 它的 Audio Location 值为 Front Right。Initiator 中的应用程序需要确保它向每个设备发送正确的音频数据。但是，发起方的应用程序可以更改这一点，该应用程序可以将所需的任何音频流定向到每个 CIS。这听起来可能违反直觉，但在某些应用中可能是有意义的。想想人们坐在网球场上听比赛解说。如果网球场两侧的人都接收到相同的立体声输入，那么球场一侧的人会听到球走错了方向。在这种情况下，他们可能想要 “镜像” 声音，交换左右音频内容。这不会影响他们的音频位置 –它会受到发起方为每个 CIS 交换内容的影响。
对于广播，耳塞或扬声器将使用其音频位置来确定它想要接收的音频流，每个耳塞都可以独立做出选择。在大多数情况下，耳塞还会与关联的远程控制设备共享其音频位置，该设备可以通过重新配置每个耳塞的音频位置值来执行相同的镜像作。
对于单播流，由 Initiator 决定将哪些内容发送到每个 Audio Location，因此应用程序可以控制接收的内容。当我们在第 7 章的第 7.4 节中了解如何配置 CIS 时，将对此进行解释。
对于广播流，广播发射器和耳塞之间没有链接，情况略有不同。广播发射机不知道哪些设备正在收听它。为了适应这种情况，许多人将传输三种不同的音频流 – 左流、右流和单声道流。在这种情况下，可以接受左流的 Acceptor 需要决定是同步到左流还是 mono流。应该有一个用户可以配置的默认值，或者一个从用户界面中选择的选项，该选项可能位于远程控制设备上。
音频位置在蓝牙通用音频分配编号中定义，并遵循 CTA-861-G 表 34 代码的扬声器放置分类。它们存储在 Sink 和 Source Audio Location 特征中，这些特征在 PACS 中定义。这些值表示为四个八位字节宽位域中的位。最常见的 Audio Locations 如表 3.1 所示。
|
Audio Location
| Value (bitmap) |
| No specified Audio Location (e.g. mono audio) | 0x00000000 |
| Front Left | 0x00000001 (bit 1) |
| Front Right | 0x00000002 (bit 2) |
| Front Centre | 0x00000004 (bit 3) |
| Low Frequency Effects 1 (Front Woofer) | 0x00000008 (bit 4) |
| Back Left | 0x00000010 (bit 5) |
| Back Right | 0x00000020 (bit 6) |
每个可以接收音频流的 Acceptor 必须至少设置一个 Audio Location。音频位置通常在制造时设置，但在某些情况下，用户可能会更改它 - 例如，扬声器可能有一个应用程序或物理开关将其设置为左前、右前或未分配，这被解释为单声道。
在蓝牙 LE 音频规范的第一个版本中，未定义单声道。这遵循了数字电视的 CTA-861 规范的概念，该规范认为 mono 不是一个位置，而是流的一个属性。这在开发人员中引起了巨大的混淆，并引入了一些实现问题，因为广播接收器只能通过省略其 Audio Location特性来表明它想要选择 mono。该规范的最新更新现在要求 mono 设备将其 Audio Location 值设置为 0x00000000 才能接收 mono 流。
目前，音频源（如麦克风）没有音频位置的定义，但假设音频位置是指捕获音频的位置。
在大多数情况下，捕获的音频是单个单声道流，因此没有音频位置，但如果两个麦克风都被采样和传输以帮助消除噪音，一对耳塞可能希望区分左右。
在第 5 章中，我们将进一步了解音频位置 （Audio Locations） 的使用方式，但现在我们已经介绍了它们，我们可以继续查看 Channel Allocation。
3.11 通道分配（多路复用）
您始终知道 Bluetooth Classic Audio 配置文件中传输的内容。HFP 携带单声道音频流。A2DP 有更多选择，因为强制性 SBC 编解码器可以将流编码为单声道、双声道、立体声或联合立体声。在大多数 implementations 中使用 jointstereo，因此所有设备都接收左声道和右声道。相比之下，LC3 编码单个通道。为了适应这一点，蓝牙 LE Audio 更加灵活，允许 CIS 或 BIS 包含一个或多个多路复用到单个数据包中的音频通道，仅受可用带宽的限制。
采用这种方法的原因是 LC3 是所有蓝牙 LE 音频实现的强制编解码器，它是一个单通道编解码器。这意味着它将每个音频通道单独编码为固定长度的离散帧。使用 SBC 时，联合立体声编码（将左右音频通道组合成一个编码流）很受欢迎，因为它比编码两个单独的左右通道更有效。自编写 SBC 以来的 30 年里，编解码器技术取得了长足的进步。LC3 更高效的设计意味着与单独编码每个通道相比，联合立体声编码几乎没有优势。这样就可以优化无线电的导通时间和功耗，只传输每个设备需要的音频数据，而不是让所有设备都接收两个立体声通道，然后扔掉不需要的数据。
但是，某些实现可能仍希望将多个蓝牙 LE 音频通道连接到单个数据包中。对于条形音箱和立体声耳机等只需要单个同步声道的设备，这将稍微更有效。在这些应用程序中，通道分配 [BAP Section 4.2] 可用于连接各个编码帧，从而允许将多个音频通道组合在一起。
图 3.7 显示了一个 5 声道环绕声系统的工作原理示例。使用 LC3 对 5 个音频输入通道进行单独编码，然后将编码的帧排列成一个媒体包，该媒体包作为单个同步 PDU 传输。
LC3 编解码器帧始终使用表 3.4 中总结的分配编号，按与每个音频声道关联的已发布音频功能音频位置的升序排列。因此，在这种情况下，它们将按左前 （0x0000000001）、右前 （0x0000000002）、中前 （0x0000000004）、左后 （0x0000000010） 和右后 （0x0000000020） 排序。请注意，单声道不能包含在媒体数据包中，因为 0x00000000 的音频位置值不能与任何其他音频位置位同时指示。
媒体数据包仅包含编码的音频帧。它可以扩展为包含多个编码的音频帧块，每个块都包含每个 Audio Locations 的一帧，如图 3.8 所示。CF_Nrefers 到每个传入的音频通道;CF_Nto这些音频通道的下一个采样中的那些。
使用块可能看起来很有效，但它也有一些重要的警告。它会导致更大的数据包，更容易受到干扰。它还会增加延迟，因为 Controller 需要等待多个帧采样后才能开始传输。如果将多个 block 添加到 Burst Number 或 Pre-Transmission Offset 的多个 Isochronous Channel 功能中，我们将在下一章中介绍，它很快就会导致数百毫秒的延迟。在某些情况下，这可能很有用，但在我们今天使用的一般音频应用程序中没有。
没有与媒体数据包关联的标头信息。相反，可以支持的音频通道数在 Supported_Audio_Channel_Counts LTV 中指定，该 LTV 包含在 PAC 记录的编解码器特定功能 LTV 中，每个同步流的值由发起方在流配置过程中设置。正在使用的区块数量是使用 Codec_Frame_Blocks_Per_SDU LTV 结构同时配置的。
我们将在第 5 章讨论 LC3 和服务质量时更详细地介绍这些内容。
3.12 音频数据的演示延迟和序列化
支持两个耳塞给我们带来了蓝牙 LE Audio 必须解决的另一个问题，即确保左耳和右耳的声音同时呈现。过去，音频数据被发送到单个设备，该设备知道如何提取左右信号并同时渲染它们。借助蓝牙 LE Audio，CIes 使用不同的传输槽将数据串行传输到不同的目的地。尽管传入的音频通道在同一时间点向 Initiator 提供数据，但编码的数据包会一个接一个地到达 Acceptor。它们可能会因重传而进一步延迟。图 3.9 通过在图 3.6 的 CIG 图上添加左右数据包进入两个接收器的示例来说明这一点.
这种序列化会导致一个问题。人头非常善于检测左耳和右耳之间声音到达时间的差异，并使用该差异来估计声音的来源方向。
图 3.10 表明，如果你离音频源 2 米远，并且你只将头旋转 10 度，这相当于声音到达时间的差异刚刚超过 70 μs。如果左耳和右耳之间的渲染时间存在变化，您的大脑会将其解释为声源移动。如果这种差异远超过 25 微秒并且经常变化，你就会开始产生令人不快的效果，感觉就像声音在你的脑海中移动一样。为了防止这种情况，重要的是要有一种同步技术来确保左右耳塞始终在同一时间呈现各自的音频数据。
我们不能依赖两个耳塞之间的任何蓝牙通信。正如我们之前所说，人的头部在衰减2.4GHz 信号方面非常有效，因为它含有大量的水。如果您的小耳塞整齐地贴合耳道，则无法保证它们能够相互通信。
蓝牙 LE Audio 解决方案分为两部分。首先，两个耳塞都需要知道一个公共同步点，这是每个 Acceptor 都可以保证其他每个 Acceptor 都有一切可能的机会接收传输的数据包的时间点，无论是单播还是广播流。此时间点必须由 Initiator 提供，因为它是唯一知道将数据包发送到所有 Acceptor 需要多少次尝试的设备。（请记住，Acceptor 通常无法相互交谈，并且很可能不知道彼此的存在。
在大多数情况下，Acceptor 将比该公共同步点更早地收到其音频数据包，因为在音频应用程序中，数据包被安排多次重传，以最大限度地提高接收机会。这是因为由于数据包丢失，音频流中会出现 dropout 问题。这些对于听者来说特别烦人，因此使用重传来帮助提高信号的稳健性。这意味着每个 Acceptor 都需要包含足够的缓冲来存储从最早的到达时间 - 其数据包首次传输的时间，直到公共 Synchronization Point 的数据包。我们将在第 4 章中了解有关 Synchronization Point 的更多信息。
但是，您无法在 Synchronization Point 处渲染音频，因为它仍处于编码状态。在同步点和最终渲染点之间，需要对数据进行解码，并执行任何其他音频处理，例如数据包丢失隐藏 （PLC）、主动降噪 （ANC） 或助听器音频调整，然后才能最终渲染数据。
此处理所需的时间可能因不同的 Acceptor 而异。虽然您希望一家制造商成对提供的一对助听器、扬声器或耳塞设计为每个耳塞具有相同的处理时间，但如果接收器来自不同的制造商，或者即使固件更新应用于一个，而不是另一个，情况可能会有所不同。因此，蓝牙 LE音频规范包括 Presentation Delay 的概念。Presentation Delay 是一个参数，其值由Initiator 设置，用于指定在每个 Acceptor 中渲染音频时，同步点之后的时间（以微秒为单位）。如图 3.11 所示。SDU 同步点的“C>P”后缀是指中心到外围方向（启动器到接收器）。LL 是指控制器中的链路层，这是接收无线发送的数据的地方。
用于渲染的 Presentation Delay 还可能包括一个 Host 应用程序依赖元素，以故意增加渲染时间。这是链接到视频的音频流的常用技术，可用于延迟渲染点以补偿口型同步问题。对于公共广播应用程序，可能有多个广播发射机覆盖一个大型礼堂或体育场，演示延迟也可用于设置特定的延迟，以补偿为每个观众组提供服务的广播发射机与音频源之间的不同距离。声音每秒传播 343 米，因此声音可能需要半秒钟才能传播到大型体育场。因此，场馆通常会对扬声器应用延迟，以帮助同步场馆不同部分的声音。使用多个蓝牙 LE音频广播发射机的演示延迟可以实现相同的效果，使观众更接近声音的来源。
每个 Acceptor 都包含它可以支持的最小和最大 Presentation Delay 的值。最小值表示在渲染声音之前，它可以解码接收到的编解码器数据包并执行任何音频处理的最短时间;最大值反映了它可以添加到该缓冲中的最长缓冲量。这些值由发起方在配置期间读取，它必须遵守它正在传输的每个流中所有接受方的最大值和最小值。这意味着它不能设置大于任何 Acceptor 的最低 Presentation_Delay_Max 值的值，也不能小于他们中的任何一个都Presentation_Delay_Min。接受器还可以公开其首选的Presentation Delay 值，发起方应尝试使用该值，除非发起方上的应用程序需要特定值，因为它可能用于实时应用程序或补偿口型同步。预计 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 超出其可以支持的范围时 Broadcast Sink 应该做什么。
为了允许广播应用程序具有更低的延迟，广播发射器可以在其广播音频流终端节点中包含
一个特殊的 LTV 标志，称为广播音频即时渲染标志。当出现这种情况时，Acceptor 可以单方面决定尽快渲染传入流，而忽略 Broadcast Source 设置的 Presentation Delay值。如果有一副耳塞或助听器，他们需要就这个值是多少达成一致，但他们如何做到这一点超出了规范。它通常会在制造过程中设置。
对于单播和广播，顶级配置文件可以为 Presentation Delay 指定特定值，尤其是在它们支持低延迟应用程序时。例如，如果音频流也存在环境声音，则它们可能需要使用“Live” 上下文类型，以及不超过 20 毫秒的 Presentation Delay 设置（用于 HAP 或TMAP 支持）。
演示延迟也适用于音频捕获，其中音频数据从接收器传输到启动器（在规格中表示为 P>C或外围设备到中心）。在这里，它表示从捕获音频，然后进行后续处理、采样和编码，到第一个同步的第一个数据包的参考点的时间Stream 可以传输，如图 3.12 所示。
在音频捕获中使用 Presentation Delay 可确保每个麦克风或其他音频传感器在完全相同的时间点捕获声音。它定义了一个间隔，在此期间，每个 Acceptor 都可以准备其音频数据包进行传输，第一次传输发生在 Presentation Delay 结束时。然后，所有其他音频数据源都将在其分配的传输槽中传输其编码的数据包。当手机想要组合来自左右耳塞的麦克风数据时，这是可取的，因为它可以使用常见捕获时间的知识来组合它们。Initiator 通常会利用这些知识来通知数字拼接技术，以便在运行噪声消除算法之前对齐多个流，但这超出了蓝牙规范，而不是基于捕获时间进行简单的混合，但这超出了蓝牙规范。
虽然在单播音频源中捕获演示延迟最常见的用法是每个耳塞或助听器中都有一个麦克风，但它对于具有多个麦克风的单个设备同样有效。这包括立体声麦克风和立体声耳机，每个罐子里都有一个麦克风。在这些设备中，实现可以使用通道分配将两个麦克风信号编码到单个编解码器帧中以进行多路复用（请参阅下面的第 3.11 节），或使用 Presentation Delay 分别传输它们以确保捕获对齐。在这两种情况下，都需要设置 Presentation Delay的值以涵盖音频处理和编码时间。
当麦克风间隔较远时，接收到的数据将不会反映其位置之间的音频路径差异。如果Initiator 想要恢复该信息，则可能需要调整它收到的传入流的相对时间。由于Initiator 会安排所有传入的音频数据，因此这些流没有指定的参考点，因为假定实现知道每个音频流何时到达。
重要的是要了解 Presentation Delay 仅适用于 Acceptor，无论它是充当 Audio Sink 还是 Audio Source。在许多情况下，Acceptor 将同时充当两者。通常，每个 Presentation Delay 的值都不同
3.13 遥控器 （Commanders）
蓝牙一直是遥控器的不错候选者，但这些几乎都是简单的遥控器，本质上是传统红外遥控器的蓝牙替代品。助听器和耳塞使远程控制成为一个有吸引力的选择，因为这些设备非常小，以至于它们没有空间容纳很多按钮，即使它们有，纵您看不到的按钮（因为它在你的头的侧面或耳后）是一种糟糕的用户体验。由于大多数耳塞都与手机、笔记本电脑或 PC一起使用，并且生成音频流的应用程序通常包含用于暂停音频流、接听电话或更改音量的控件，因此这不是一个主要问题。但是，当助听器仅用于放大环境声音时，助听器用户也需要控制助听器的音量。
为了比在助听器上摸索按钮更容易，该行业开发了简单的、类似钥匙扣的遥控器，允许用户轻松调节音量或更改音频处理算法以适应他们的环境（这些被称为预设设置）。即使助听器包含蓝牙技术，大多数情况下用户也不会启用有效的蓝牙链接，从口袋或包中取出手机，然后找到合适的应用程序是一种不方便的音量调节方式。如果您被巨大的噪音所困扰，将助听器取出会更快、更容易，这不是一个好的用户体验。
蓝牙 LE Audio 的新广播功能将带来更多的公共基础设施，用户将需要浏览多个不同的广播并决定接收哪些广播。这不仅在助听器或耳塞上很难做到，而且还涉及相对耗电的扫描。为了解决这些问题，开发了一个单独设备的概念，它可以提供音量控制，发现和显示可用的广播源，发现加密广播的密钥，并允许助听器用户更改他们的预设。也可以使用它来接听电话或控制媒体播放器。这些设备承担 CAP 中定义的 Commander 角色，但也可以使用 BAP 的 Broadcast Assistant 角色来发现广播，以及作为内容控制客户端。大多数顶级配置文件为这些设备可以代入的其他 Role 引入了更多名称。对于本文档的其余部分，我将使用 Commander 术语，除非它是针对 Broadcast Assistant 的特定子集的。
Commander 是蓝牙 LE Audio 拓扑的重要新增功能。该角色可以在手机上实现，既可以作为独立应用程序实现，也可以作为电话或音频流应用程序的一部分实现。它也可以在任何具有 Bluetooth 连接到 Acceptor 或 Coordinated Sets of Acceptor 的设备中实现。
这意味着您可以在专用遥控器、智能手表、腕带甚至助听器和耳塞的电池盒中实现它。
Commander 可以有一个显示屏来显示有关广播的文本信息，以帮助您选择它们，或者只显示音量按钮。Commander 按照先到先得的原则工作，因此您可以拥有多个 Commander，当您想改变音量或将助听器静音时，可以使用先到的那个。由于所有函数都已明确指定，因此这也意味着多个设备可以互作地实现它们。在第 12 章中，我们将研究它们可能会改变我们未来使用蓝牙音频设备方式的一些方式。
在介绍了这些新概念之后，我们现在可以深入研究规范，了解它们的工作原理以及它们如何为蓝牙 LE Audio 启用新的用例。
扫一扫
1086
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
