机器翻译结果，仅用于学习，不喜勿喷，原文档链接。
在本章中，我们将了解如何配置广播音频流。广播是蓝牙® LE Audio 的主要新功能，有可能改变每个人使用音频的方式。它引入的令人兴奋的用例包括共享音频的能力，以及建立临时私人连接的能力。后者由 BASS 中定义的广播助手功能启用，并带来全新的控制和用户体验。
再一次，主要spec是 BAP——基本音频profile，但我们现在需要添加另一个 GAF spec，称为 BASS——广播音频扫描服务。 BASS 定义了如何使用附加设备来帮助查找广播音频流并指示一个或多个acceptor与它们同步。
CAP 再次发挥作用。除了提供设置和接收广播流的程序外，它还定义了commander的角色。 Commander 可以是物理设备，也可以是手机或电视上的应用程序。在了解发送和接收广播音频流的基础知识后，我们将更详细地了解commander角色。 CAP 的主要任务是制定有关关联Context类型和内容控制 ID 的规则，并重复需要完成的事情的顺序。
我们将从设置和接收广播音频流的基础开始，然后看看commander给图片带来了什么。在第 12 章中，我们将深入探讨广播音频的可能性，研究它可以实现的一些新用例。
尽管广播拓扑起源于提高感应式听力回路提供的质量的愿望，但LE audio 提供的多功能性远远超过感应式回路。在许多情况下，除了广播源和commander之间的连接之外，广播源和广播接收器之间还会有一个 ACL 连接。设备甚至可以同时支持广播和单播，充当广播和单播连接之间的中继。但在我们进入这些复杂性之前，我们将从广播本身的基础开始。
广播spec分为三个独立的功能：
- 传输广播音频流。在最简单的情况下，广播器（这是一个更容易用于广播源的名称）独立运行 - 它通常不知道是否有任何接收器存在并正在收听它。
- 查找广播音频流。这通常会使用广播助理，通常称为commander（尽管从技术上讲，这只是一个角色，广播助理是其中的一个子角色）。广播助手可以找到广播接收器的广播音频流。广播助手将广播从一个简单的感应线圈替代品提升为一个非常强大的新拓扑，它允许在个人和基础设施级别将加密流用于私人音频。它们还使在多个广播音频流中进行选择变得更加容易。广播助手可以设计为独立设备，也可以与任何广播源搭配使用。
- 接收广播音频流。广播接收器（本质上与广播接收器相同）可以扫描广播音频流的存在并与之同步。在这个基本层面上，它也独立运作。 Broadcast Receiver 可以同步到加密或未加密的广播音频流，但需要获取 Broadcast_Code 才能解密加密的音频流。这可以在带外完成，也可以在广播助理的帮助下完成
8.1 设置广播源
在第 4 章中，我们介绍了广播等时流 (BIS) 和广播同步组 (BIG) 的基础知识。与单播流不同，广播源和广播接收器独立运行。这使得广播源与任何其他蓝牙central非常不同，因为它是单方面的。与我们在前一章探讨的单播情况不同，设备之间不会发生任何命令、请求或通知。相反，广播源完全由其特定应用程序驱动。
这样做的一个结果是广播源有一个非常简单的状态机，如图8.1。由于没有与任何Acceptor交互，因此过程非常简单，包括从host到广播源中的controller的命令。
要配置广播源，host需要向controller提供 BIG 配置的详细信息。controller使用它来调度 BIS。它还需要提供用于填充 BASE 的信息，该信息描述了每个 BIS 的配置及其内容。配置数据由运行广播源的应用程序提供。在某些应用程序中，包含在 BASE 中的metadata可能是应用程序的一部分；在其他情况下，它可能是从外部提供的，或者从控制输入，或者从传入的音频流中提取，例如电视的电子节目指南数据。
BAP 为广播流的转换和配置更新定义了六个过程：
- Broadcast Audio Stream configuration procedure
- Broadcast Audio Stream establishment procedure
- Broadcast Audio Stream disable procedure
- Broadcast Audio Stream Metadata update procedure
- Broadcast Audio Stream release procedure
- Broadcast Audio Stream reconfiguration procedure
由于设备之间没有连接，这些过程大多仅限于 HCI 命令，在 Initiator 准备好开始广播时发送。 CAP 将它们捆绑成五个程序，将配置和建立组合到其广播音频启动程序中：
- Broadcast Audio Start procedure
- Broadcast Audio Update procedure
- Broadcast Audio Stop procedure
- Broadcast Audio Reception Start procedure
- Broadcast Audio Reception Stop procedure
8.2 启动广播音频流
由于广播源不知道什么可能正在接收其广播音频流，因此与协调集有关的 CAP 前导程序都不相关。 CAP 所要求的只是metadata中包含正确的Context类型。仅当伴随的 ACL 连接携带来自广播源的内容控制时，才需要内容控制 ID。这在个人电视等应用程序中是必需的，它使用广播允许多个家庭成员收听，但他们的个人耳塞可用于暂停或更改频道。
我们需要的所有其他内容都在 BAP 中定义，其中程序指示controller设置Extended Adv并提供数据以填充在Extended Adv和 Periodic Advertising train中公开的参数。
图 8.2 采用了第 4 章中的Extended Adv图，并突出显示了设置广播源所需的特定数据元素。设置广播音频流的第一步是组装controller填充广播音频公告服务、BIGInfo 和 BASE 所需的所有数据，这在 BAP 音频流建立过程 [BAP 6.3] 中进行了描述。
8.2.1 配置BASE
应用程序将确定要传输的 BIS 数量及其相关的编解码器和 QoS 配置。 BAP 建议至少一个广播音频流应该使用表 3.2 的 16_2 或 24_2 设置进行编码，即 16kHz，10ms SDU 或 24kHz，10ms SDU，以确保每个acceptor都可以对其进行解码。任何其他附加编解码器配置将由应用程序或更高级别的profile确定。host还应获取填充 BASE 所需的任何metadata内容。当前的metadata要求如表 8.1 所示。
| Profile | Required LTV metadata structures | Comments |
|---|---|---|
| BAP | None | |
| CAP | Streaming_Audio_Contexts | |
| CAP | CCID_List | Only if content control exists for the Audio Stream |
| HAP | None | Inherited from PBP |
| TMAP | None | |
| PBP | None | ProgramInfo is recommended to describe the Audio Stream |
配置流所需的最后一条信息是 Presentation Delay 的值，该值通常由 QoS 设置确定。
controller现在可以将其 BASE 结构组合在一起，该结构准确地描述了它将传输的流及其配置。
我们在第 4 章中对 BASE 进行了概述，查看了它包含的内容，在图 8.3 中重复了这些内容。
整个 BASE 是一个 LTV 结构，以 AD 类型表示，参数如表 8.2 所示。
BASE 具有很大的灵活性，其中大部分在大多数日常应用中都不需要。级别 1 参数必须存在并适用于每个子组。大多数 BIS 可能只有一个子组，通常带有两个或三个 BIS——一个用于左侧，一个用于右侧，以及可选的单声道或联合立体声流。定义多个子组的原因是某些 BIS 具有不同的metadata，例如不同的语言。像这样的差异只能用 2 级参数来表示。在级别 3，您可以为子组内的 BIS 指定不同的编解码器配置，例如具有不同的质量级别，例如一个流采用 48 kHz 采样，一个流采用 24 kHz。但这是在第 3 级时唯一发生变化的事情。不同的语言、不同的父母等级等，都需要在第 2 级定义自己的子组。
如果有多个 BIS，则应按照子组和 BIS_index 的顺序为每个 BIS 重复第 2 级和第 3 级参数部分，如表 8.3 所示。
| Level | Parameter | Value |
|---|---|---|
| 2 | Num_BIS [0] Codec_ID [0] Codec_Specific_Configuration LV [0] Metadata LV [0] | Num_BIS = 2 |
| 3 | BIS_index [0[0]] Codec_Specific_Configuration LV [0[0]] | 0x01 |
| 2 | Num_BIS [0] Codec_ID [0] Codec_Specific_Configuration LV [0] Metadata LV [0] | Num_BIS = 2 |
| 3 | BIS_index [0[1]] Codec_Specific_Configuration LV [0[1]] | 0x02 |
| 2 | Num_BIS [1] Codec_ID [1] Codec_Specific_Configuration LV [1] Metadata LV [1] | Num_BIS = 2 |
| 3 | BIS_index [1[0]] Codec_Specific_Configuration LV [1[0]] | 0x03 |
| 2 | Num_BIS [1] Codec_ID [1] Codec_Specific_Configuration LV [1] Metadata LV [1] | Num_BIS = 2 |
| 3 | BIS_index [1[1]] Codec_Specific_Configuration LV [1[1]] | 0x04 |
8.2.2 创建BIG
正如我们在单播中看到的那样，BIG 是使用 HCI 命令创建的——在本例中是 LE Create BIG 参数，其参数如表 8.4 所示。
| Parameter | Description |
|---|---|
| BIG_Handle | 由host设置的 BIG 标识符。 |
| Advertising_Handle | 关联的Periodic Advertising序列的handle。 |
| Num_BIS | BIG 中的 BIS 数量。 |
| SDU_Interval | 包含编码音频数据的周期性 SDU 之间的间隔，以微秒为单位。 |
| Max_SDU | 每个 SDU 的最大大小，以八位字节为单位。 |
| Max_Transport_Latency | 每个 BIS 的最大传输延迟，包括预传输。 |
| RTN | 请求的重传次数（这是一个建议） |
| PHY | 可接受的 PHY 值的位域。controller将从支持的选项之一中进行选择。高级profile可能只要求一个值——通常为 2Mbps。 0 = 1Mbps, 1 = 2 Mbps, 2 = LE coded. |
| Packing | 安排 BIS subevent的首选方法。controller仅将此用作建议。0 = Sequential, 1 = Interleaved. |
| Framing | 如果设置为 1，BIS 数据 PDU 将被framed。如果设置为 1，则controller可以决定是使用framed还是unframed。 |
| Encryption | 如果音频流需要加密，则设置为 1，未加密则设置为 0。 |
| Broadcast_Code | 用于为 BIG 中的所有 BIS 生成加密密钥的代码。对于未加密的流，这应该设置为零。 |
LE 创建 BIG 参数命令和等效的 LE 设置 CIG 参数命令之间的一个重要区别是 BIG 中的每个 BIS 都使用相同的参数。该限制源于同步Channel信息包含在 BIGInfo 数据包中的事实，该数据包不足以容纳多个不同 BIS 的详细信息。结果是每个 BIS 的大小相同，必须适合最大的 SDU。 BIG 中的不同 BIS 可能使用不同的编解码器配置甚至不同的编解码器，但 BIS 结构必须配置为适合这些不同配置中的最大可能数据包。如果 BIG 中的不同 BIS 使用不同的 QoS 设置，则意味着会有冗余空间。
创建 BASE 结构后，host可以使用 LE_Create_BIG 命令（在核心第 4 卷 E 部分第 7.8.103 节中定义）请求controller调度 BIG 和 BIS，参数如表 8.4 所示。
一旦命令发出并且controller已经制定了它的调度，它将使用包含它选择使用的实际参数的 LE_Create_BIG_Complete 事件 [Core Vol 4, Part E, Sect 7.7.65.27] 响应host，如如表 8.5 所示。其中一些由host应用程序使用，另一些将反映 BIGInfo 中的内容 - 通知扫描设备广播等时流配置的数据结构。
| Parameter | Description | Used in |
|---|---|---|
| Subevent Code | 0x1B – Subevent code for the LE_Create_BIG_Complete event | Host |
| Status | Set to 0 if the BIG could be successfully scheduled; otherwise set to 1, when an Error Code is available. | Host |
| BIG_Handle | The same BIG handle the Host sent in its LE_Create_BIG command | Host |
| BIG_Sync_Delay | The maximum time for transmission, in microseconds, of all PDUs of all BISes in a single BIG event, using the actual parameters included below. | Host |
| Transport_Latency_BIG | The actual transport latency for the BIG in microseconds. (This covers all BIG events used for an SDU.) | Host |
| PHY | The PHY that will be used for transmission. | BIGInfo |
| NSE | The number of Subevents for each BIS | BIGInfo |
| BN | The Burst Number. (The number of new payloads in each BIS event.) | BIGInfo |
| PTO | The offset used for pre-transmissions. | BIGInfo |
| IRC | The Immediate Repetition Count. (The number of times a payload is transmitted in each BIS event.) | BIGInfo |
| Max_PDU | The maximum size of the payload in octets. | BIGInfo |
| ISO_Interval | The value of the Isochronous Interval. (The time between consecutive BIG Anchor Points.) Expressed as a multiple of 1.25 msecs. | BIGInfo |
| Num_BIS | The total number of BISes in the BIG | BIGInfo |
| Connection Handle[i] | A list of Connection Handles for all of the BISes in the BIG |
此时，host拥有启动流程所需的一切，第一阶段是设置Extended Adv和Periodic Advertising火车。需要在AUX_ADV_IND Extended Announcements中包含Broadcast Audio Announcements [BAP 3.7.2.1]和Broadcast_ID [BAP 3.7.2.1.1]，以及包含BASE [BAP 3.7.2.2]和BIGInfo的Basic Audio Announcement
host使用 HCI_LE_Set_Extended_Advertising_Data 命令 [Core Vol 4, Part E, Sect 7.8.54] 并进入广播模式 [Core Vol 4, Part C, Sect 9.1.1] 开始Extended Adv，然后使用 HCI_LE_Set_Periodic_Advertising_Data 命令 [Core第 4 卷，E 部分，第 7.8.62 节] 填充 BASE，然后进入Periodic Advertising模式[核心第 4 卷，C 部分，第 9.5.2 节]。
一旦建立了Extended Adv和Periodic Advertising序列，广播音频源就进入配置状态。在这个阶段，它还没有传输任何音频数据。
8.2.3 更新广播音频流
在任何时候，广播源都可以更新包含metadata的 BASE 中的 LTV 结构。这通常是为了反映音频通道内容的变化，例如新的 ProgramInfo 或Context类型。这在 BAP 修改广播源过程 [BAP 6.5.5] 中定义。广播者不需要停止音频流，但可以在配置或流媒体状态时动态更改。
无法保证正在接收音频流的 Acceptor 会看到这样的变化。一旦 Acceptor 使用 BIGInfo 中的信息同步到流，它就不再需要跟踪 Periodic Advertisements 或读取 BASE，除非另一个profile要求这样做。
8.2.4 建立广播音频流
运行扩展和Periodic Advertising后，广播源需要建立其音频流并开始传输。它分三个步骤执行此操作，由 BAP 广播音频流建立过程 [BAP 6.3.2] 定义。
首先，它进入广播同步广播模式[核心卷 3，C 部分，第 9.6.2 节]，准备在其 BIG 的 BIS 中发送 PDU。然后它启动广播同步同步模式 [核心卷 3，C 部分，第 9.6.3 节]，它开始在周期性Advertising的 ACAD 字段中发送 BIGInfo，提醒任何正在扫描广播音频流的设备它的存在。
最后，广播源需要以与单播相同的方式设置音频数据路径，使用 LE Setup ISO Data Path HCI 命令 [Core Vol 4, Part E, Sect 7.8.109]。
此时，广播源已完全运行，正在传输其 BIG 和组成 BIS。如果它没有连接，它永远不会知道是否有任何设备检测到或同步到这些广播。
8.2.5 停止广播音频流
要停止广播并返回到已配置状态，Initiator 需要使用广播同步终止过程 [Core Vol 3, Part C, Sect 9.6.5]。这将停止 BIS PDU 和 BIGInfo 的传输。同步的Acceptor将收到一个 BIG_TERMINATE_IND PDU 来提醒它们传输结束。如果他们没有收到此信息，除了 BIS 和 BIGInfo 都已消失这一事实之外，他们不会获得更多信息。
在广播同步终止过程结束时，广播源将返回到配置状态。然后可以释放或重新启用它。
8.2.6 发布广播音频流
要将广播源返回到其空闲状态，它需要退出周期性Advertising模式，这会将其返回到空闲状态。
8.3接收广播音频流
如果一个广播接收器想要接收一个广播音频流，它需要扫描找到它。使用相同的查找它的过程，无论是由广播接收器本身还是由广播助手完成。我们将在本节中只看广播接收器的工作，然后看看当广播助手可用时如何委派任务。
因为acceptor充当独立的实体，所以 CAP 并没有真正用于接收广播音频流。 CAP 定义了广播音频接收开始过程 [CAP 7.3.1.8]，但除非Acceptor有一种相互通信的方式，否则他们不知道对方的存在。他们知道自己是协调集的成员，但不知道其他集成员是否在附近。commander可以完成我们稍后会谈到的协调任务，或者可能存在带外机制，例如允许Acceptor相互交谈的 sub-GHz 无线电。但是Acceptor 本身的扫描本质上是在BAP 级别上运行的。
8.3.1 音频公告发现
接收广播流的第一步是找到它，这是使用来自核心的观察程序 [Core Vol3, Part C, Sect 9.1.2] 执行的。这是查找Advertising的标准扫描。在这里，感兴趣的是Extended Adv，其中包含带有 Broadcast_ID 的广播音频公告服务 UUID。Extended Adv还可能包括其他服务 UUID，例如公共广播profile中定义的那些，扫描器可以使用它来过滤它想要调查的流。
找到适当的Extended Adv后，扫描器将查找 SyncInfo 数据并使用它与与 Broadcast_ID 关联的周期性Advertising同步。同步后，扫描器可以找到并解析 BASE 中的数据，该数据提供有关 BIS 集的信息。
此时，Acceptor 的行为与之前的蓝牙外设完全不同。它不是被central告知要做什么，而是收集范围内具有感兴趣的音频流的可用广播源的信息，并自行决定接收哪一个。这完全由实施驱动。它可能会查找它之前已连接到的已知 Broadcast_ID，或 BASE metadata中的信息。它可以连接到它找到的第一个流，然后逐步遍历任何其他可用的流，或者它可以从范围内的每个广播源收集数据并以某种形式将其呈现给用户，以允许他们进行手动选择。所有这些都是特定于实现的。
Acceptor可以使用附加信息来告知其选择。如果它们的Context类型不匹配任何acceptor的可用Context类型，它通常不会打扰流。它也不想接收它不支持的音频位置的流。但决定权在Acceptor手中。如果没有 Commander 或两个 Acceptor 之间的专有链接，用户可能不得不在左右耳塞上手动选择流。这种情况不太可能发生，因为这是一种糟糕的用户体验；制造商将提供单独的 Commander（或 Commander 应用程序），或在左右耳塞之间实现专有链接。但是，设计人员应该意识到，当设备之间没有蓝牙链接时，需要允许设备对一起工作。但这就是远程遥控/commander的用武之地。
8.3.2 同步到广播音频流
一旦它决定接收一个广播源，接收器就会启动广播音频流同步过程 [BAP 6.6]。这涉及它从 AUX_SYNC_IND（和任何补充的 AUX_CHAIN IND）PDU 中读取 BASE 信息，以确定编解码器配置和对应于Acceptor音频位置的 BIS 索引号。每个 BIS 的 BIS_Index 定义 BIG 中 BIS 的顺序。知道了这一点，Acceptor 可以确定它想要接收 BIG 中的哪些 BIS。
然后，Acceptor 检索 BIGInfo，其中包含 BIG 结构、跳跃序列和 BIS 锚点所在位置的所有信息。一旦有了这个，它就可以从核心调用广播等时同步建立过程[第 3 卷，C 部分，第 9.6.3 节]，以获取适当的 BIS。如果尚未这样做，则需要设置其音频数据路径。收到传入的音频数据包后，它会应用 Presentation Delay 值来确定渲染点。
8.3.3 停止同步到广播音频流
如果 Acceptor 决定停止接收广播音频流，它会自动断开音频数据路径并停止与 PA 和 BIS 的同步。
8.4 广播接收用户体验
虽然允许Acceptor自己获取Broadcast Stream，但用户体验不是很好。在最基本的情况下，它与 Telecoil 体验完全类似，佩戴助听器的人按下其 Telecoil 按钮以获取 Telecoil 流。这种用户体验是有效的，因为感应线圈是感应回路，您通常只在一个回路的范围内，这意味着您是否连接到正确的回路没有问题。如果范围内只有一个LE audio 发射器，那体验将是相同的，但一旦广播应用变得流行，这将不再是真的；在许多情况下，您可能处于许多广播发射机的范围内。这与我们使用 Wi-Fi 的情况完全相同。如果您使用手机或笔记本电脑扫描 Wi-Fi 接入点，您经常会发现十几个或更多。LE audio 的用户体验可能要困难得多，因为在大多数情况下，您会佩戴一副具有最小用户界面的耳塞或助听器。还需要一起开始和停止流式传输，并且始终将两个耳塞连接到同一个广播源，这也增加了复杂性。
因此，尽管上面的解释是有效的，并指出了如何接收广播流，但它们在很大程度上是学术性的。为了使这项工作在现实世界中发挥作用，我们需要使用另一台设备来更好地完成查找广播流并告诉一个或多个Acceptor如何处理它们的艰苦工作。我们还需要一种方法来分发解码加密音频流所需的密钥。这将我们带到了commander和广播助理。
8.5 BASS – Broadcast Audio Scan Service
首先，简单介绍一下 BASS - Broadcast Audio Scan Service 。 BASS 是一种服务，它在 Acceptor 中实例化，以公开它所知道的广播音频流的详细信息，它连接到的音频流的详细信息，以及它是否需要广播助手来帮助它管理该信息并帮助它制作连接。 BASS 与广播助手（在 BAP 中定义，我们将在稍后介绍）一起管理他们选择和管理的广播连接。它是扩展广播生态系统的关键部分，使用 ACL 连接来辅助广播信息的分发和控制。
BASS 的关键元素是两个特性，无论何时使用，这两个特性都是必需的：
| Characteristic | Properties | Quantity |
|---|---|---|
| Broadcast Audio Scan Control Point | Write, Write w/o response | Only one |
| Broadcast Receive State | Read, Notify | One or more |
广播音频扫描控制点特性允许一个或多个广播助手通知Acceptor他们是否正在代表Acceptor积极工作以寻找广播源。他们可以告诉 Acceptor 如何找到 BIG、连接到 BIG、断开与 BIG 的连接并提供 Broadcast_Code 来解密加密的音频流。正如我们将看到的，广播音频扫描控制点特性中有一个非常重要的参数，即 BIS_Sync。当 Broadcast Assistant 将此设置为 0b1 时，它会告诉 Acceptor 开始接收流。当它设置为 0b0 时，Acceptor 应该停止接收它。
上一段第一行的“一个或多个广播助理”声明很重要。 Acceptor 可以使用任意数量的广播助手。所需要的只是每个都有一个到该acceptor的 ACL 链接。一旦他们连接并注册了他们正在帮助 Acceptor 查找广播流的事实，广播助手将按照先到先服务的方式运行，仅受 CSIP 调用的任何锁的限制，如果他们’在一组协调的acceptor上重新操作。每个广播助手都需要向广播接收状态注册以获取通知，这意味着只要广播状态发生更改，无论是通过广播助手写入它，还是作为本地操作的结果，所有这些都将被更新在Acceptor上。
广播接收状态特性暴露了acceptor正在做什么——它连接到哪个 BIG，它当前正在接收该 BIG 中的哪些 BIS，它是否可以解密它们以及它为每个它们拥有的当前metadata。对于可以同时同步的每个 BIG，Acceptor 必须至少具有一个广播接收状态特征。在许多情况下，这只是一个。现在说commander。
8.6 commnder
尽管大多数人将广播视为LE audio 的一大新功能，但最重要的创新可能是 Commander 的概念，它提供广播音频流的远程控制和管理。在多个广播流的新世界中，commander为用户提供了一种简单的方式来选择他们听到的内容。尽管广播概念的灵感来自于在助听器中拾取感应回路的 Telecoil 体验，但LE audio 广播应用远远超出了 Telecoil 的能力。
回顾归纳循环范例，这很简单——如果你站在循环的边界内，你只会收到音频流。 （如果您在房间正上方，可能会出现问题，但这是一个边缘情况。）使用蓝牙广播，它们可以并且将会重叠并穿过墙壁，因此用户需要一种简单的方法来选择他们想要的广播听。我们已经看到 BASE 中的metadata信息和来自公共广播profile (PBP) 等profile的服务信息如何帮助告知该选择。但是，这仅适用于公共广播，任何人都可以收听。对于个人广播，广播音频流是加密的，需要获取加密密钥的方法。再一次，这是由commander启用的。
CAP 中定义的角色，但我在本书中更普遍地使用它们。将 Commander 本身可视化为一种设备（例如电视远程遥控）很有用，因为对于用户而言，它的作用非常相似。commander通常包含四个主要元素：
- CSIP Set Coordinator，它确保将任何命令发送到 Coordinated Set 的所有成员，无论是关于广播源的信息还是音量控制。
- 广播助手，用于扫描广播源并让用户选择他们想要收听的广播源，
- 一个 VCP 音量controller（我们将在第 10 章中介绍）来控制 Coordinated Set 中每个成员的音量，以及
- 获取和分发广播代码以解密广播音频流的能力
如果没有 Commanders 带来的灵活性以及它们提供的功能，广播加密就会变得很麻烦，使得围绕私有广播流的用例很难实现。私人广播为LE audio 带来了全新的维度。无论是用于个人电视和音乐、在酒店房间访问电视、在会议室共享音频，还是新的蓝牙音频共享体验，它都依赖于用户连接到正确广播源并获得访问权限的简单方式到 Broadcast_Code 以解密音频。所有这些都由 BAP 中定义的两个新角色管理。他们是Scan Delegator和广播助手。他们与广播音频扫描服务 (BASS) 合作，分发信息收集和控制，从而提供丰富的广播应用程序。
8.6.1 广播助手
广播助手允许其他设备执行我们在第 8.3.1 节中描述的扫描作业。广播助理角色通常是独立commander的主要角色，代表广播接收器进行扫描。卸载此任务有两个重要原因。首先是扫描是一项相当耗电的操作，这是您不希望助听器或耳塞做的事情，或者至少不经常这样做，尤其是在不知道它到底在寻找什么的情况下。在电话或专用远程遥控等设备上执行这项工作要好得多，它们都不是由微型锌空气电池供电。第二个原因是用户体验。广播应始终在其基本结构中包含可读的metadata，从而允许带有显示器的设备显示每个内容。显示该信息在手机或远程遥控上很容易实现，但在耳塞上几乎不可能。因此，将扫描和选择任务移到其他地方不仅可以节省电池寿命，还可以极大地改善用户体验。
广播助手具有与acceptor的 ACL 链接。如果 Acceptor 正在运行基于 CAP 的profile，它们可能是 Coordinated Set 的成员，在这种情况下，包括 Broadcast Assistant 的每个 Commander 都必须运行 CAP 前导程序以确保它在所有集合成员上运行。可以涉及多个commander，因此用户可以在智能手表及其智能手机中拥有commander应用程序，并且还可以使用专用远程遥控作为额外的commander。
8.6.2 Scan Delegators
commander代表具有Scan Delegator角色的设备工作。该角色在 BAP 中定义，通常在广播接收器中实现。它的工作是找到其他扮演广播助手角色的设备，它可以接管扫描广播者的工作。 Scan Delegator 也可以在 Commander 中实现，因为多个 Commander 可以链接在一起，有效地将信息从一个传递到另一个。我们将在后面的章节中看到这样做的好处。
Broadcast Sink 中的 Scan Delegator Role 始终包含 BASS 实例。Scan Delegator请求广播助手，广播助手可以通过使用Extended Adv PDU 发送请求请求来代表他们进行扫描，Extended Adv PDU 包括包含 BASS UUID 的服务数据 AD 类型。
范围内的任何广播助手都可以连接并让 Scan Delegator 知道它已经代表它开始扫描，通过广播接收器上的 BASS 实例进行交互，它在广播接收器上写入广播音频扫描控制点特征 [BASS 3.1]，以确认它正在积极扫描（操作码 = 0x01）或已停止扫描（操作码 = 0x00）。由 BASS 实例为多个client记录此状态以确定是否有任何client正在主动扫描。这个代表Scan Delegator进行扫描的过程称为远程广播扫描。一旦它知道广播助手正在代表它进行扫描，广播接收器可能会决定终止它自己的扫描过程以节省电力。广播助手可以读取广播接收器的 PAC 记录以发现其功能，并使用该信息过滤它找到的广播源，以便它只向Scan Delegator提供对其广播接收器有效的选项。最常见的是，这将考虑广播接收器的音频位置、支持和可用的Context类型以及它支持的编解码器配置。
一旦广播助手检测到合适的广播源，它可以通过写入其广播接收状态特征之一来通知Scan Delegator，以启动广播接收器获取广播音频流的过程。这可以是自动操作，也可以是用户启动的。用户可能希望自动连接到已知的广播源，例如当他们走进礼拜场所或办公室时。或者，他们可能会要求他们的手机进行扫描，并让他们知道使用扫描应用程序可以使用哪些内容，然后再选择他们喜欢的广播源。该选择是特定于实现的。
8.6.3 向 BASS 添加广播源
一旦在commander上做出选择，广播助手将其写入广播接收器上的第一个空广播接收状态特征，添加选定的广播源信息 [BAP 6.5.4]。在它这样做之前，它应该已经读取了广播接收状态特性的当前状态。如果用户选择了其中一个已经存在的广播源，那么它应该使用修改广播源过程[BAP 6.5.5]修改适当的广播源值。它还应该检查广播接收器是否能够解码任何建议的音频源。
它使用 0x02 [BASS 3.1.1.4] 的 Add Source Operation 操作码写入特征的参数分为三大类，如表 8.7 所示。
第一组参数——Source Information，通知Broadcast Sink广播源和BIG的身份，以便它知道该信息指的是哪个设备（或更准确地说，设备身份）。Advertising集 ID – SID，包含在主要Advertising中，在设置Extended Adv时定义 [第 4 卷，E 部分，第 7.8.53 节]，通常在设备的生命周期内保持静态，并且不不允许在电源循环之间更改。虽然它只是一个八位字节，但它可以帮助识别设备。 Broadcast_ID 位于 Extended Advertising 的 AUX_ADV_IND 中，并且在 BIG 的生命周期内是静态的（可能比 SID 短）。连同Advertising地址，这是广播接收器扫描广播源的足够信息。
下一组参数告诉广播接收器它应该做什么。这通常由用户在其commander的用户界面上选择广播源来触发。 PA_Sync 告诉它同步到周期性的Advertising序列，这让它获得 BASE和BIGInfo。将 PA_Sync 设置为 0x01 或 0x02 会告诉广播接收器去做。 PA_Interval 是连续 AUX_ADV_IND 数据包之间的间隔，如果已知，可以帮助到扫程序。 Num_Subgroups 提供了 BASE 中子组的数量，其次是最重要的参数，即 BIS_Sync。
BIS_Sync 是从 Commander 到 Acceptor 的指令，告诉它要连接到哪个特定的 Broadcast Stream 或 Streams。它是所有 BIS 的四个八位字节宽的位图，对于acceptor应连接到的任何流，其值都设置为 0x01。这里有一点微妙之处，这就是为什么它是排列的，而不是单个八位字节，因为它对每个子组都有效地被屏蔽了。因此，每个 BIS_Sync[i] 仅对该子组有效——所有其他值都设置为 0b0。这样做的原因是，Acceptor 永远不会期望同时接收来自不同子组的 BIS，因为子组的全部意义在于将关联的流安排在一起。如果两个子组使用不同的语言，例如日语和德语，则期望您只会选择一种。
图 8.5 说明了子组中的 BIS_Index 值如何与 BIG 中的排序相关，其中 BIS 按数字顺序排列。在这种情况下，它们与 BIS_Index 值不一致，因此是 BIS_Index 的映射。在写入 BIS_Sync 值时，只能选择一个子组。因此，如果从图 8.5 中选择子组 0，则 BIS_Sync[0] 唯一允许的值是将位 0 和 1 之一或两者设置为 0b1。
Broadcast Assistant 可以将 BIS_Sync 的值设置为 0xFFFFFFFF，意思是“无偏好”，在这种情况下，Broadcast Sink 可以自行决定使用哪些 BIS。
最后，metadata字段为每个子组提供 2 级metadata——通常是音频Context和音频位置，允许Acceptor决定它们是否适合它想要做的事情，即它们是否匹配其当前可用的音频Context类型设置。 Add Source操作中发送的数据，写入每个Broadcast接收状态，可以随时通过Modify Source操作修改，更新当前信息。尽管在这两个操作中传递了特定的连接信息，但它是否遵循与 PA 同步的请求以及写入它的 BIS 完全取决于 Acceptor。这取决于实施。
如果 Acceptor 决定按照 Commander 的指令采取行动，它将使用指令同步到 Periodic Advertising 序列，或者通过使用 PAST，或者使用它提供的 Broadcast Source 信息进行扫描，从 ACAD 中检索 BASE 和 BIGInfo和 PA 中的基本音频公告。这些为它提供了与 BIG 同步所需的所有信息，之后它将使用 BIS_Sync 值来选择它接收的特定 BIS 或 BIS。
PAST – Periodic Advertising同步传输过程 [核心，第 6 卷，B 部分，第 9.5.4 节] 是最有效的方法，因为广播助手向Scan Delegator提供 SyncInfo 数据，使其能够直接与 PA 同步。此过程称为扫描卸载。
Acceptor 可以自主执行断开连接，或者 Commander 可以使用 Modify Source 操作将相应的 BIS_Sync 位设置为 0b0。它还可以告诉 Acceptor 停止与 PA 同步，但保留其余的 Source 信息。或者，它可以通过对该 Source_ID 执行 Remove Source 操作来删除 Source 记录。
8.6.3.1 Set, Source and Broadcast ID
值得快速了解这些操作中涉及的不同 ID，因为它们可能会造成混淆。
参考图 8.6，Set 和 Broadcast ID 是 Broadcast Source 的属性。两者都是随机生成的数字。 Advertising Set_ID 包含在主要Advertising中，并标识一组特定的扩展和 Periodic Advertising train。 SID 在设备的整个生命周期内通常是静态的，但必须在每个电源周期内保持不变。当 Acceptor 或 Commander 想要定期重新连接到已知源（无论是个人设备还是固定的基础设施广播发射器）时，SID 会很有用。
Broadcast_ID 特定于 BIG，并在广播音频公告服务 UUID 中携带。它在 BIG 的生命周期内保持不变。
Source_ID 是 Acceptor 生成的编号，用于标识一组特定的广播设备和 BIG 信息。它是 Acceptor 本地的，用作 Broadcast Assistant 的参考。在acceptor的协调集的情况下，例如左耳塞和右耳塞，Source_ID 不相关并且可能不同，即使两者都接收相同的 BIS，因为每个acceptor独立地创建自己的源 ID 值。
8.6.4 广播接收状态特性
在acceptor上，广播接收状态特性用于通知任何广播助手其关于广播音频流的当前状态。其结构如表 8.8 所示。
| Field | Size (Octets) | Description |
|---|---|---|
| BIG_Encryption | 1 | Encryption status: 0x00 – Not encrypted 0x01 – Broadcast_Code required 0x02 – Decrypting 0x03 – Bad_Code (wrong encryption key) |
| Bad_Code | Varies | If BIG_Encryption = 0x03 (wrong key), this contains the value of the current, incorrect key. Otherwise not present. |
| Num_Subgroups | 1 | Number of subgroups |
| BIS_Sync_State[i] | 4 | BIS synchronisation state for the ith subgroup |
| Metadata_Length[i] | 1 | Length of the metadata for the ith subgroup |
| Metadata[i] | varies | Metadata for the ith subgroup |
与其他可以由client操作设置的特性一样，以及由一个自治的server操作更改，广播接收状态特性可以被client用来检查操作和状态，也可以由server通知来表示比一个操作完成，例如同步到一个 PA，或者从一个client请求一个动作。当他们收到通知时，其中一些充当错误报告，而另一些则向广播助理发出请求。其中，最重要的是通知 0x01 的 PA_Sync 状态以请求 SyncInfo，并通知 0x02 的 BIG_Encryption 状态以请求广播代码。 BIS 同步的任何自主变化或 BIS 丢失都可以通过更新的 BIS_Sync_State 通知。
8.7 Broadcast_Codes
加密广播音频流的能力将LE audio 带入了音频应用的全新领域。加密有效地提供了一种伪地理围栏功能，将广播覆盖范围限制为拥有解密密钥的人。这可以用来限制对特定区域中重叠广播的访问，就像使用 Wi-Fi 代码一样。例如，酒店可以分配代码以防止人们收听相邻会议室或楼上电视的音频。通过提供通过蓝牙链接发送加密密钥的方法，或者允许广播助手使用带外方法获取它，它变得更加强大。在第 12 章中，我们将研究为不同应用程序分发 Broadcast_Code 的不同方式。
实现音频共享的个人设备，例如电视、平板电脑和笔记本电脑，可以将广播助手与广播源搭配使用。然后，Assistant 可以直接访问 Broadcast_Codes，并可以将它们直接写入 Broadcast Sink。它要求acceptor与广播源配对，但这对于个人设备来说是预期的。
Broadcast_Code 的生命周期取决于实现。在某些情况下，它可能是永久性的——在咖啡店播放音乐的广播源可能永远不会更改其代码。只要客人住在那个房间里，酒店房间里的电视就会保持它的 Broadcast_Code；个人电视可能会在每次电源循环时更新它，因此访问过的朋友不会无限期地保留它，而与您的朋友共享音频的手机应用程序可能会在每次会话时更新它。这些不同的生命周期意味着广播源和commander需要支持多种不同的方法来获取广播代码。
8.8 接收广播音频流（使用commander）
了解commander后，我们可以重新审视现实世界中设备如何接收广播流，这几乎总是涉及commander，无论是独立设备、可穿戴设备、手机上的应用程序还是广播助手内置于广播电视。
8.8.1 Solicitation Requests
Scan Delegator的第一项工作是为自己找到一些广播助手，它通过发送包含服务 AD 数据类型的Extended Adv来完成此操作，该服务 AD 数据类型包含广播音频扫描服务 UUID。这些被称为Solicitation Requests [BAP 6.5.2]。
图 8.7 显示了一个扫描委托器发送包含 BASS 服务 UUID 的Extended Adv。在左侧，三名广播助理在范围内。广播助手#1 与广播接收器并置并正在积极扫描。广播助手#2 和#3 是仅具有commander角色的设备，但只有广播助手#3 正在主动扫描。在这种情况下，广播助手#1 和#3 都应该响应请求请求。
CAP 和往常一样，告诉每个广播助手从连接开始，建立协调集的成员，然后布置要遵循的 BAP 程序。此时，每个广播助手都应该读取每个广播接收器的 PAC 记录以确定它们的能力，主要是因为它们没有必要将广播接收器无法接受的广播音频流告诉广播接收器。做出这个决定可能有很多原因。这可能是因为广播音频流的用例具有广播接收器无法支持的Context类型；它可能具有无法解码的编解码器配置，具有不兼容的通道分配或音频位置，需要加密等，等等。
一个 Coordinated Set 中只有一个 Acceptor 需要执行 Solicitation 过程。一旦广播助手做出响应并确定它是协调集的成员，CAP 会要求它找到其他成员，然后读取他们所有的 PAC 记录，然后与每个成员上的 BASS 实例进行交互。
图 8.7 显示了广播助手#3 的该过程的简化示例，它响应协调集的一个成员的请求请求。它连接到 Broadcast Sink #1 中的 Scan Delegator，发现它是两个 Acceptor 的协调集的成员，然后找到并连接到第二个成员。
它发现并读取每个 Acceptor 的 PAC 记录，并将设置其广播过滤策略，以便它只报告两个 Acceptor 都可以接收的广播音频流。
接下来，它将发现并读取 BASS 广播接收状态，并为这些特征设置通知，以便它知道任何变化。读取状态告诉它acceptor当前是否同步到任何Periodic Advertising train或正在接收任何 BIS。一旦完成这些过程，它就准备好代表Acceptor开始扫描，并写入他们的广播音频扫描控制点特征以通知他们这一点。
一旦完成并且代表Scan Delegator至少有一个活动的广播助手扫描，我们进入 BAP 的广播助手程序，从远程广播扫描 [BAP 6.5.3] 开始。
8.8.2 远程广播扫描
通知Scan Delegator它正在扫描的广播助手将开始搜索广播发射器。当它找到每个Advertising集时，它将通过扩展和周期性Advertising（AUX_ADV_IND 和 AUX_SYNC_IND）工作，检查内容并解析结构以确定广播音频流是否与acceptor的功能匹配。在大多数情况下，它会建立一个相关的、可用的广播音频流列表并将它们呈现给用户。如果 Commander 具有合适的用户界面，例如智能手机上的应用程序，则可能会以排序列表的形式呈现，用户可以从中选择要连接的广播音频流。
图 8.9 接续图 8.8，其中广播助手 #3 代表两个广播接收器（此处显示为单个实体）进行扫描。它发现了Broadcast Source B和Broadcast Source C。用户决定Commander收听Broadcast Source C并选择它，此时Broadcast Assistant #3将Broadcast Source C的信息写入Scan中的BASS实例两个广播接收器的委托人。
图 8.9 还显示了并置的广播助手的行为方式。在这种情况下，Broadcast Assistant #1 与 Broadcast Source A 搭配使用。Broadcast Assistant #1 从未写信给 Broadcast Scan Control Point 说它正在代表 Scan Delegator 进行扫描，因为它的唯一目的是提供 Scan Delegator以及有关其并置广播源的信息。一旦它连接到扫描委托器，它就可以将该信息写入广播接收状态。 （并置的广播助手也可以执行扫描，在这种情况下，它会告诉Scan Delegator它正在代表它进行扫描，但这是一种实现选择。）
需要牢记的一点是，广播助手中的接收器可能比耳塞中的接收器具有更好的灵敏度，因为它们可能具有更大的天线。这意味着他们可能会检测到超出其广播接收器范围的广播源。实现可能想要确定来自广播源的信号的 RSSI，并使用该信息来安排向用户呈现广播源的顺序。
8.8.3 接收广播流
我们现在处于用户已经决定他们想听什么的时候，这将我们带回到添加广播源的操作，我们在第 8.6.3 节中描述了该操作。在大多数情况下，当用户在其 Commander 上选择广播源时，广播助手不仅会将该源的详细信息写入广播音频扫描控制点特性，还会设置 PA_Sync 和 BIS_Sync 参数以指示每个acceptor开始接收相关的流。
由于两个 Acceptor 是独立行动的，因此它们可能需要不同的时间来获取 PA 序列，然后才能与适当的 BIS 同步，特别是在它们必须扫描而不是使用 PAST 的情况下。这可能会导致音频开始在两个耳塞中呈现的时间之间出现明显的延迟。蓝牙spec不包含有关如何解决此问题的任何详细信息，但一种方法是让commander分两个阶段执行此操作，首先设置 PA_Sync 位，等待两个acceptor同步的通知，然后仅在该点发送a Modify Source 操作，指示它们同步其 BIS 并接收和渲染音频。
8.8.4 Broadcast_Codes（重访）
在第 12 章中，我们将看到 Broadcast_Codes 对于新的音频应用程序的重要性。如果我们回顾图 8.9，并假设来自广播源 A 和广播源 C 的广播音频流都是加密的，那么获取两个 Broadcast_Code 的方式可能会略有不同。
Broadcast Source A 的 Broadcast Assistant 知道 Streams 的 Broadcast_Code——这就是为什么要搭配它。因此，一旦用户选择广播源 A，Broadcast_Code 将在添加源命令中发送。
在广播源 C 的情况下，广播助手可能不知道代码，特别是如果它没有与广播源 C 配对。在这种情况下，Scan Delegator之一可以询问其所有广播助手是否知道广播代码，通过通知适当的接收状态特征，将 BIG_Encryption 字段设置为 0x01，表示它需要 Broadcast_Code。如果广播接收器已经有这个流的广播代码，它不再起作用（通常是因为它是在更早的会话中获得的），它应该将 BIG_Encryption 字段设置为 0x03 以指示不正确的广播代码，并将该值包含在 Bad_Code 字段中，以便具有相同错误代码的广播助手不会浪费时间重新发送它。如果任何广播助手知道代码，则可以通过使用设置广播代码操作 (0x04) [BASS 3.1.1.6] 将 Broadcast_Code 值连同 Source_ID 写入Scan Delegator的广播音频扫描控制点来响应此通知。
正如我们将在第 12 章中看到的，广播助手可以通过一系列带外方法获取 Broadcast_Code，从而开辟一些有趣的新用例。其中一些可能会直接触发广播音频流的获取过程。
8.8.5 结束广播音频流的接收
广播音频流的接收可以由acceptor自主执行，在这种情况下，它将在其广播接收状态特性中通知此更改。如果commander收到此通知并且知道Acceptor是协调集的成员，它可以决定通过在其广播音频扫描控制点中写入适当的值来终止其他Acceptor的接收。但是，这是特定于实现的。
或者，用户可以使用命令器通过写入每个acceptor的广播音频扫描控制点来停止接收，所有子组中的所有 BIS 的 BIS_Sync 值设置为零，PA_Sync 值设置为 0x00。一旦acceptor通过通知其广播接收状态特性（PA_Sync_State 和 BIS_Sync_State[i] 均设置为零）来指示它不再与 BIS 或 PA 同步，广播助手应执行删除源操作 (0x05) [BASS 3.1.1.7] 删除相关的广播接收状态。请注意，广播接收器没有状态机。它使用其广播接收状态特性来同步或发布广播音频流。
8.9 广播和单播之间的切换
CAP 中定义了两个切换过程，以涵盖发起方想要在单播和广播流之间移动（反之亦然）以传输相同音频内容的用例。这与从单播用例更改为广播用例的一般情况不同，而是特定于与朋友共享个人音频之类的应用程序，其中用户想要从单个个人流转换为广播流，或相反亦然。 CAP 中的过程允许 Acceptor 从 Initiator 接收并发的单播和广播音频流，目的是使切换可以是无缝的，流中没有明显的中断。 （在大多数情况下，情况并非如此，因为 Acceptor 将没有资源同时接收两种类型的流，尤其是当它们使用更高采样率的 QoS 配置之一时。）提供流畅的监听根据经验，实现应该尝试隐藏原始Acceptor传输中的任何中断，尽管这可以通过听得见的音调或消息来完成。 （加入广播音频流的朋友不会遇到任何中断，因为他们不会收到原始音频流。）
程序 [CAP 7.3.1.10 和 7.3.1.11] 还要求将用于原始流的任何 Streaming Context Types 和 CCID_List 转移到重新配置的流中。尽管原始流的用户已将其从单播转换为广播，但他们仍将保持与其音频源的 ACL 连接并期望任何控制功能继续进行，例如快进或音量控制，因此需要维护 CCID协会。接收广播的其他人将只能访问音频。
8.10 Presentation Delay – 设置广播值
通过单播，Acceptor 让Initiator 通过公开其最大和最小Presentation Delay能力以及他们的首选值范围来了解他们支持Presentation Delay的能力。在广播中，Initiator 和 Acceptor 之间没有信息传递。这意味着Initiator 设置的值可能不会被所有决定接收它的Acceptor支持。
BAP 要求所有广播接收器必须在其范围内支持 40ms 的值，因此这可能是许多initiator将使用的默认值。但是，它开始引入延迟，这对于实时音频来说可能是过度的。
TMAP 和 HAP 对 Presentation Delay 的值有更严格的限制，要求 Acceptor 必须支持 20ms。由于大多数 Acceptor 都应该符合 TMAP 或 HAP（大多数可能同时支持两者），因此将 Broadcast Source 设置为 20ms 似乎是一个合理的折衷方案。但是，仅符合 BAP 的设备可能不支持此功能。
这就提出了一个问题，如果 Acceptor 不支持广播源公开的 Presentation Delay 的值，它应该做什么。spec对此没有提及，但以下指南提供了一种实用的方法。
- 如果 Presentation Delay 低于 Acceptor 可以容纳的值，它应该使用 40ms 的值（所有设备都必须支持）。
该spec给广播源三个八位字节来携带Presentation Delay值。这超过了 65 毫秒的限制，如果只使用两个八位字节（单位为 1 微秒），这将是最大值，但这意味着该值可能高达 16.7 秒。大多数 Acceptor 用于缓冲音频流的内存有限，因此在某些情况下，Presentation Delay 的过高值可能超出了它们的能力范围。虽然他们可以决定不渲染音频流，但实用的方法是恢复到 40 毫秒的 BAP 值。
在这两种情况下，这将确保左右设备同时渲染。如果他们能够相互通信，他们可能会使用专有方法来确定最合适的值，这通常会选择他们支持的最低共同值。
2186
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
