12 Auracast

本文AI翻译自Bluetooth SIG官方文档,仅用于学习交流

在蓝牙LE audio规范开发初期,一项关键需求是支持广播音频。这项需求来自助听器社区,他们正在寻找一种能够补充拾音线圈电感环路的方法,同时提供更简便、更具可扩展性的安装方式,并支持多个重叠音频流。随着规范工作的推进,越来越多的消费音频公司开始看到广播的潜力,并加入了开发进程。如今,蓝牙 LE audio的广播功能被许多人视为其最重要的特性,它为所有人——而不仅仅是助听器用户——带来了共享音频。随着开发人员逐渐了解其优势,并利用其功能推出新的音频体验,可以说,这可能是自 20 世纪 50 年代末立体声诞生以来消费音频领域最大的变革。

与许多此类新技术一样,它要求设计师重新思考他们的产品制造方式。音频的发展历史大多是渐进式的——由于更好的组件和更高效的编解码器,音频质量会定期得到小幅提升。数字技术帮助改变了音频内容的传输方式,最初是从磁带和黑胶唱片转向CD,后来也实现了流媒体的访问。伴随着这些变化,用户体验也变得越来越个性化,音频源可以流式传输到一组音箱、耳机中。唱片行业对维护这种模式有着既得利益,因为在这种模式下,每个用户都购买相同内容的单独访问权限。这种商业模式催生了一种开发者思维模式,他们迟迟未能意识到广播音频带来的新自由,以及为了充分利用这些自由,需要做出哪些设计选择。

为了驱动新的使用模式,用户需要能够从多个不同的广播流中进行选择。经典的蓝牙模式以手机为中心,手机成为用户唯一的音频来源。用户可以访问选择列表来切换耳机和音箱,但这种体验主要体现在切换播放设备,而且几乎总是由手机发起。相比之下,广播音频将手机视为众多潜在音频源之一,由耳机或充当其代理的设备做出选择,从而有效地扩展了用户界面。这就是我们在 8.6.1 节中介绍的广播助手的作用。它可以作为同一部手机上的应用程序实现,但可以采用多种不同的物理形式。这种将您正在收听的内容的控制权转移到播放音频的设备的概念被称为“接收器主导的旅程”。正是这种理念促成了公告和非连接模型的引入,而这些正是支持这种新的多功能性的根本原因。

随着多种公共广播源和个人广播源的出现,有必要确保一套最低限度的通用功能,以保证所有用户的互操作性。这些功能既需要涵盖助听器等注重延长电池续航的设备,也需要涵盖个人设备,因为行业优先考虑最高的蓝牙低功耗音频质量。为了解决这些问题,蓝牙技术联盟 (Bluetooth SIG) 开发了 Auracast™ 品牌,该品牌为广播音频源制定了指导方针,以确保互操作性。Auracast™ 名称和徽标可用于推广符合 Auracast™ 简易发射器最佳实践指南的产品。它还可以作为合规音频广播可用性的公开声明,类似于使用拾音线圈和 Wi-Fi 徽标来指示无线服务的可用性。Auracast™ 徽标如图 12.1 所示。有关使用要求的详细信息,请参阅蓝牙商标品牌指南。
在这里插入图片描述

图12.1 Auracast™ 图形标记

12.1 基本原则

为了帮助手解这些准则的制定原因,我们不妨先了解一下 Auracast™ 的一些预期用例。这些用例阐明了一些需要解决的兼容性问题,以确保一致的用户体验,帮助消费者对 Auracast™ 品牌产品始终有效充满信心。

12.1.1 个人电视

最简单的用例之一是两个人正在看电视,如图 12.2 所示。其中一个人戴着耳塞,另一个人戴着耳机。

实现这一点的方法有很多种。最简单的两种是:
· 电视中集成了广播发射器,以便用户可以从电视菜单或遥控器中选择 Auracast™ 传输。
· 独立的 Auracast™ 发射器插入电视背面的一个音频输出口。

表面上看,这很简单,但其中有几个重要的细节。首先,两个用户可能想要接收不同的流。其次,他们可能也在其他广播发射器的覆盖范围内,因此需要一种方法来确保他们接收到正确的广播流。

在这里插入图片描述

图12.2 一个简单的电视广播音频用例

从多路广播流的需求开始,两个用户可能出于多种原因希望接收不同的音频流。首先是出于清晰度的考虑。如果您佩戴耳机,您最关心的通常是尽可能清晰地听到电视节目中的对话。为了实现这一点,越来越多的电视节目加入了“听力增强”或“对话辅助”流,这些音频经过混合处理,以降低背景噪音并增强语音。这使得听力受损的听众更容易理解对话。

第二个原因是,越来越多的节目支持多语言音轨。在这两种情况下,蓝牙 LE audio都支持同时播放多个蓝牙 LE audio流,以便不同的用户可以选择自己想听的内容。

推动使用多流的第三个更微妙的考虑因素是,大多数助听器没有足够的资源来解码电视供应商默认设置的高质量编解码器配置。解码这些QoS数据包会对助听器的电池寿命产生不利影响。因此,所有兼容Auracast™的电视都需要包含一个无障碍聆听模式,以平衡所有用户的需求,并且不排除听力障碍用户。这可能意味着电视需要能够以两种不同的QoS配置播放相同的内容。

12.1.2 公共场所

Auracast™ 旨在彻底改变公共场所的助听体验。目前,安装喇叭存在物理困难,通常仅在建筑初期或大型翻新工程中安装。Auracast™ 可以通过简单便携的设备提供同样的功能,可随时安装。

图 12.3 展示了一款包含广播发射器的手持式麦克风。它提供单声道音频流,可供多个用户接收和播放。这些用户可能佩戴单个或一对助听器、耳机或耳塞。相同的广播音频信号也可用于驱动场地内的 PA 扬声器,为房间内的每个人提供完整的低延迟音频系统。图12.3 中的麦克风可以轻松替换为独立的 Auracast™ 发射器,只需将其插入现有调音台或音频系统的音频输出即可。

在这里插入图片描述

图12.3 典型的公共 Auracast™ 部署

它展现了 Auracast™ 为公共音频带来的便捷。无需拉线、无需调音台、无需感应线圈。整个PA 系统和 Auracast™ 覆盖只需几分钟即可在任何场地安装完毕,开机即可立即运行。它将彻底改变音频安装方式,因为它是一种经济实惠的方式,能够满足各种用户音频需求。

第三个例子,我们通常所说的“健身房”或“运动酒吧”场景,那里有多台静音电视,播放着不同的节目。佩戴 Auracast™ 耳机或助听器的用户可以从多个频道中选择自己想听的频道。

在这里插入图片描述

图12.4 拥有多台静音电视的体育酒吧或健身房

图 12.4 展示了三台电视的用例,每台电视显示不同的频道。同样,任意数量的用户可以选择自己想听的频道。由于所有这些发射器都服务于同一区域,因此用户需要一种方法来选择正确的广播频道。最简单的方法是使用我们在 11.9 节中介绍的广播音频 URI,为每个不同的节目提供二维码,如图12.5所示。这些可以在任何方便的位置显示。

要开始接收自己喜欢的流媒体,用户只需用手机扫描相应的二维码即可。或者,他们也可以使用广播助手扫描广播信息,但这需要更多用户交互。

在这里插入图片描述

图12.5 体育酒吧多屏幕二维码示例

在这样的场景中,可能会有额外的复杂性。每台电视可以呈现多个不同的音频通道,以提供不同的QoS设置或不同的语言。还有一些实际考虑。虽然家用电视(如图 12.2 中的示例)可能包含内置 Auracast™ 发射器,但在健身房或体育酒吧等场所,可能会有多个屏幕显示相同的视频内容。与其在每台电视中配备单独的发射器,不如通过包含多个 Auracast™ 发射器的中央控制盒进行传输,该控制盒还将视频流分发到多个显示器。这取决于场地所有者。目前为公众提供多屏幕的公司可能会将托管的 Auracast™ 基础设施添加到其未来的商业产品中。

Auracast™ 在电视应用中还有更多应用,我们将在接下来的章节中介绍其中的一些,但我们刚刚介绍的这些应用涵盖了实施者为实现全球互操作性需要解决的主要设计问题,这些问题使客户无论在产品上还是在场所看到 Auracast™ 的名称或标识,都能放心地选择和使用 Auracast™。首先是广播发射器的要求,这些要求已发布在《Auracast™ 简易发射器最佳实践指南》中。

12.2 Auracast™简易发射器最佳实践指南

为了确保互操作性承诺的兑现,蓝牙技术联盟 (Bluetooth SIG) 制定了《Auracast™ 简易发射器最佳实践指南》,其中列出了广播发射器必须支持的功能,才能使用 Auracast™ 一词来描述或推广自身。该指南并未定义新功能,而是规定了 Auracast™ 品牌产品必须支持的蓝牙 LE audio规范中的一系列功能和行为。引述其简介,该指南“对广播音频设备施加了某些设计原则,包括所有产品通用的选定音频流参数。这些设计原则有助于确保各种播放设备与公共和个人 Auracast™ 发射器之间的全球互操作性”。

回到蓝牙 LE audio广播的基本前提,发射器不知道是否有任何接收方正在监听其音频流,也不知道任何尝试接收音频流的接收方的能力水平。它所能做的就是假设这些接收方支持最低的QoS 要求,这意味着它们可以接收、解码和播放采样率为 16kHz 或 24kHz、SDU 为 10ms 的非复用 LC3流。使用这些设置的广播发射器将具有全球互操作性。Auracast™ 流可能被加密,具体取决于应用程序。加密流的 Broadcast_Code 信息如何提供尚未指明。

12.2.1 标准质量公共广播音频

这些设置是 BAP 强制所有接收端 (Acceptor) 都必须遵循的设置,在 Auracast™ 简易发射器最佳实践指南中定义为标准质量公共广播音频配置,使用公共广播配置文件 (PBP) 中的“标准质量 (SQ)”定义。所有声称兼容 Auracast™ 的广播发射器都必须支持此配置的传输。如果发射器未将此配置用作默认配置,则必须按需支持。

12.2.2 公共 Auracast™ 发射器

《最佳实践指南》进一步定义了公共 Auracast™ 发射器,旨在部署在公共场所,例如商用公共广播 (PA) 系统、电视和音频流媒体播放器。这些设备的默认配置必须包含标准质量广播音频流。这应确保在公共场所的任何 Auracast™ 标识显示的地方,每位助听器、耳机和耳麦用户都能确保其设备能够接收音频流。其目的是使 Auracast™ 标识在公共场所具有与当今拾音线圈标识相同的通用互操作性含义。

12.2.3 高品质公共广播音频

尽管 LC3 的 24kHz 采样率带来的音质普遍受到听众的认可,但许多产品供应商希望使用更高的采样率来提升其产品的差异化。这导致公共广播配置文件中加入了“高质量 (HQ)”配置,这些配置也包含在 Auracast™ 简易发射器最佳实践指南中。然而,它们的使用也存在一些限制。

12.2.4 个人Auracast™ 发射器

为了将 Auracast™ 品牌应用于支持高质量广播音频配置的产品,《最佳实践指南》定义了支持高质量 (HQ) 配置的个人 Auracast™发射器。这些产品旨在供个人使用,例如智能手机、平板电脑、笔记本电脑、个人电脑、家用电视或家庭音频流媒体播放器。该定义附带一个附加说明。个人Auracast™ 发射器可以默认传输高质量 (HQ) 公共广播音频流,但必须允许用户选择标准质量 (SQ) 广播音频流,以便无法解码和播放 48kHz 采样流的设备可以访问它们。其目的是提供一种易于访问的方法,让产品所有者能够配置个人 Auracast™发射器,使其以公共标准质量配置之一广播相同的音频内容。这可以通过将其传输更改为 SQ 所需的较低采样率,或同时传输 HQ和SQ 流来实现。根据 QoS 设置和发射器上的可用资源,这可能需要终止当前的 BIG,并建立新的 BIG 来替换它。单独传输单声道、SQ 流或与 HQ 流一起传输即可满足 Auracast™ 的要求。

如何实现取决于具体实现。但是,除非广播发射器能够通过简单的用户交互实现这一点,否则 HQ 广播发射器不得标榜自己是Auracast™。

12.2.5 ADV信息

Auracast™ 简易发射器最佳实践指南的第二部分是确保发射器提供足够的信息,以便扫描设备将其识别为符合Auracast™ 标准的发射器。这要求在扩展ADV和周期性ADV中的多种ADV类型和公告中提供某些信息。图 12.6 概述了这些元素及其位置。

在这里插入图片描述

图12.6 Auracast™ 相关数据在主要、扩展和定期ADV中的位置

所有 Auracast™ 发射器必须包括:

  • 正确填充的公共广播公告。这使得扫描仪无需接收和解析定期ADV序列中的BASE信息,即可检测其是否符合Auracast™标准。
  • Broadcast_Name 公告类型,提供广播源的名称,广播助手可以在其用户界面中使用该名称,
  • 基本音频公告中的BASE 结构,其中包括包含 SQ 或 HQ 配置的subgroup。

最佳实践指南还包括使用metadata LTV 结构的其他ADV内容参数的建议。

12.2.6 附加发射器信息

Auracast™ 简易发射器最佳实践指南还涵盖了一系列物理发射器设置,包括ADV间隔、输出发射功率级别和广播音频级别。这些设置有助于在覆盖范围和发现 Auracast™ 流存在所需的时间方面提供统一的用户体验。指南还提醒实施者避免使用多路复用音频流,因为广播接收器支持多路复用音频流并非强制性要求。如果 Auracast™ 发射器需要支持立体声,则应将其作为单独的左右声道流发送。

12.3 广播助手(BSA)

有趣的是,现有的点对点蓝牙拓扑结构在开发者的思维中根深蒂固。新的广播体验意味着用户通常会处于多个广播发射器的覆盖范围内,每个发射器可能提供多个不同的音频流。用户显然需要一种方式来选择他们想听的音频,这需要一个广播助手来帮助耳塞、助听器和耳机。尽管如此,各公司在广播助手的开发上进展缓慢,导致生态系统缺少一个关键部分。

部分原因可能源于相同的历史拓扑观:手机制造商认为他们控制着一个基本上被动的播放设备,而耳机供应商则期望手机和PC能够提供选择其功能的方式。这种思维模式导致一些公司生产的产品未能充分发挥或利用广播生态系统的全部功能。对于一项新体验的初期阶段而言,这或许并不意外。未来某个时候,主要的手机和PC操作系统将集成完整的广播助手功能。与此同时,制造商可以通过创新来消除这一障碍。

12.3.1 广播助手设计

大多数使用蓝牙 LE audio的开发者都假设广播助手会以应用程序的形式在智能手机上实现。随着时间的推移,这很可能成为现实,每部智能手机都会内置一个广播助手,如图 12.7 中的示例所示。

在这里插入图片描述

图12.7 智能手机上的广播助手用户界面示例

手机应用程序是实现这些功能的一种显而易见的方式,但它对于广播助手的可能性来说却相当有限。任何带有蓝牙芯片、支持扫描扩展ADV并与协调集配对的设备都可以成为广播助手。一个有趣的广播助手实现方法是将其内置在电池盒中,就像图 12.8 中的模型一样。

在这里插入图片描述

图12.8 包含广播助手的电池盒示例

电池盒内上一个小型触摸显示屏,用于控制耳机。它可以用来控制音量,以及扫描查找附近的Auracast™ 发射器,显示其详细信息,并让用户选择想要收听的发射器。这种方法的一个特别之处是,广播助手可以在耳机制造过程中与耳机配对。这意味着用户只需将耳机从电池盒中取出,即可扫描 Auracast™ 发射器并连接到音频流,无需其他设置步骤。这几乎是尽可能好的用户体验。

在这里插入图片描述

图12.9 广播助手不同外形尺寸的示例

图 12.9 展示了更多可能的实现示例,包括一块可用作广播助手的手表、一个可让用户循环切换 Auracast™ 发射器的简易遥控器,以及一个可作为挂绳佩戴的简易电子墨水显示屏。这些简单的设备可以用单芯片实现,为开发者提供极大的自由度,实现全新的音频控制方式。

用户可以拥有多个广播助手,并且可以同时激活任意数量的助手。由于这些助手设计为可互操作,用户可以混合搭配任何制造商的广播助手。所有广播助手都必须提供相同的基本搜索和选择功能,以便用户查找和接收广播音频流。

12.4 Auracast™ 助手和接收器指南

Auracast™ 简易发射器最佳实践指南是一份相当全面的设计文档,因此,许多设计师惊讶地发现,目前还没有针对 Auracast™ 接收器或 Auracast™ 助手的类似指南。这是因为 Auracast™ 是基于所有广播接收器和助手必须实现的 BAP、BASS、PBP 和 CAP 规范的强制性要求而构建的。因此,广播发射器不应偏离 Auracast™ 简易发射器最佳实践指南的要求,因为其他功能可能并非普遍受广播接收器支持。

然而,即使具有强制性功能,也应该遵循一些基本的设计原则来帮助获得 Auracast™ 体验,特别是围绕扫描和存储有关广播音频流和发射器的信息的方式,以及音频位置的使用。

12.4.1 维护可用广播发射器的数据库

BAP 要求每个广播接收器必须能够扫描可用的广播流。如果我们考虑一个简单的用户界面,该界面可以通过用户按下单个助听器上的按钮来启动,就像目前对电感线圈的操作一样。由于广播发射器的发现顺序是随机的,因此与第一个找到的发射器同步可能不是一个好的设计选择,而不是先完成扫描,然后再进行连接选择。连接选择可能是选择之前使用过的,也可能是信号最强的——最终决定权在于实现。但是,如果您的设备需要做出选择,它需要建立一个包含已发现设备的数据库,以便提供所需的用户体验。

现有的电感线圈按钮没有理由不能具有双重功能——如果发现电感线圈环路,则选择一个可用的电感线圈环路;如果未找到电感线圈环路,则扫描 Auracast™ 发射器。

存储这些信息最明显的方法是,广播接收器为其扫描到的每个广播发射器填充一组广播接收状态特性。在 Auracast™ 的早期阶段,耳机可能只能找到一个发射器,但发射器的数量会逐渐增加。因此,广播接收器最好支持至少六个或更多广播接收状态特性实例。

在此阶段,广播接收器无需与每个PA同步。它知道每个发射器的源地址、ADV SID和广播ID,如果连接策略是重新连接到已知源,这些信息可能足以做出决策。它还应该读取公共广播公告,该公告会告知它广播发射器的名称以及它是否符合Auracast™标准。广播名称应存储在广播接收状态特性中每个subgroup的metadata中。

每个新的广播接收状态特性实例填充后,都会收到通知。如果广播接收器是协调集的成员,并且存在广播助手,则应将这些值写入另一个协调集成员的广播接收状态特性中。如果该成员也处于扫描状态,则广播助手应确保两个广播接收器中的广播接收状态特性包含相同的信息。

它们的 Source_ID 值可能不同,因为每个值都是由广播接收器本地分配的。广播助手也可能根据每个广播接收器的音频接收器位置值分配不同的 BIS_Sync 值。

如果每个活跃的广播助手正在代表任一广播接收器进行扫描,它还可以添加其获取的额外数据。这强调了广播助手和接收器实现多个广播接收状态特性实例的价值,因为它允许所有三个设备对可用的广播发射器拥有一致的了解。

当用户四处移动时,他们会进出广播发射器的范围。这意味着广播接收器需要一种策略来管理其广播接收状态列表,以确保它们保持最新。这是特定于实现的,可以由广播接收器完成,也可以委托给广播助手。由于这是特定于实现的,因此有理由由广播接收器执行这些检查,因为它无法知道是否有广播助手在代表它执行此任务。只有一个协调集成员需要执行此检查,因为它的通知应该由其广播助手转发给其他成员。

12.4.2 识别和选择广播频道

对于广播,一旦选择了广播发射器,广播接收器就需要决定各自需要连接到哪个 BIS。假设只有一个 BIG 可用,则可能会有多个subgroup,每个subgroup包含多个 BIS。这时,metadata LTV 便会为广播助手和接收器提供信息,以便它们选择BIS。

12.4.3 广播发射器中的channel分配

广播发送器使用metadata 来帮助广播接收器决定选择哪个BIS。它使用BASE结构Level 3中的metadata来实现这一点,通过包含 Audio_Channel_Allocation LTV 来识别每个 BIS 的目标音频位置。

在这里插入图片描述

图12.10 具有不同语言立体声流的两个subgroup的 BASE 结构

BASE Level 2的metadata 为 BIS 的选择提供了更多数据。图 12.10 展示了一个包含英语和西班牙语立体声流的 BIG。由于subgroup应该只包含预期作为集合播放的 BIS,因此英语和西班牙语流被分成两个subgroup。

图 12.11 展示了只有一种语言的情况,但有一个单声道音频流,该音频流已增强,可提高清晰度和立体声内容。由于这通常不会在同一设备(或一对设备)中播放,因此它被归入一个单独的subgroup。Level 2 的metadata 将其标识为辅助聆听流 (ALS)。包含单个单声道音频流的 BIS 不应包含 Audio_Channel_Allocation 的 LTV。但是,如果扫描设备检测到 Audio_Channel_Allocation 为 0x00000000,则应将其解释为单声道,因为在一些早期实现中已经出现过这种情况。

蓝牙 LE audio规范的初始版本并未明确说明广播发射器中单声道音频流的Audio_Channel_Allocation 值的使用方法。最新版本(BAP 1.0.2 和 Assigned Numbers)已对此做出澄清,明确指出该值不应出现在单声道音频流中。

metadata LTV 可以包含更多信息,以帮助广播助手和接收者做出明智的选择。由于metadata LTV 是在分配编号中定义的,因此在主要规范版本之间可能会有新的选项可用。扫描设备应该忽略 BASE 或公共广播公告中它们不知道的metadata 。

在这里插入图片描述

图12.11 带有附加辅助聆听单声道流的立体声流的 BASE

12.4.4 广播接收器中的频道选择

每个广播接收器都应具有一个“音频接收器位置”特性,用于标识其要接收的音频位置。如果设计为仅支持单声道音频流,则可以省略该特性,但缺少“音频接收器位置”特性相当于其值为 0x00000000。如果广播接收器允许更改其“音频接收器位置”特性的值(可以通过客户端写入或通过本地操作更改,例如通过物理开关将音箱设置为接收器左声道、右声道或单声道),则必须存在“音频接收器位置”特性,即使其默认值为单声道。

广播接收器使用其接收器音频位置特性的值来选择要同步并播放的subgroup中的哪个 BIS。如果 BIG 中有多个subgroup,则应首先选择subgroup。这通常基于以下两项信息:

  • 编解码器配置,其中设备可能偏好 16kHz、24kHz 或 48kHz 流,
  • level 2的metadata ,提供有关流内容的信息,例如语言以及是否是听力增强流。

请记住,我们这里讨论的是通道选择,即在所选 BIG 的subgroup中选择哪个 BIS。在大多数情况下,这会导致左耳塞或助听器选择左音频流,右耳塞选择右音频流。广播接收器应该能够自主做出这些决定,因为接收器音频位置特性值已被制造商设置为默认值,或者用户能够在耳塞设置中进行配置。当广播接收器做出自主决定时,一旦确认同步成功,它会将决定写入广播音频扫描控制点特性的 BIS_Sync 字段和所选 BIG 相应subgroup的广播接收状态特性的 BIS_Sync_State 字段.

广播接收器可以根据动态条件做出更精细的决策。如果左耳塞的“接收器音频位置”特性值表示“左”,则它也能够接收标记为单声道的音频流。如果两个音频流都可用,则由实现决定同步到这两个BIS 中的哪一个。例如,助听器佩戴者可能更希望两个助听器都接收辅助聆听单声道音频流,而不是分别接收左右声道音频流。另一个例子是用户右耳塞的电池没电了。如果另一个耳塞意识到这一点,它可能会决定将当前的左声道音频流切换为单声道音频流,以提供更好的用户体验。请注意,这些优先级选择不会暴露给广播助手 它们取决于广播接收器的自主行为。

12.4.5 广播助手的channel选择

大多数情况下,用户会通过广播助手进行选择,因为它的用户界面更丰富。广播助手通常会从其广播接收器读取 PAC 记录和接收器音频位置特性,并根据这些信息决定将哪些内容写入每个设备的广播音频扫描控制点特性的 BIS_Sync 字段,从而指示广播接收器与相应的 BIS 同步。广播接收器成功同步后,应更新其广播接收状态特性并通知同步成功。

广播助手无需指定 BIS,它可以将此选择权交给广播接收器。如果广播接收器的配置规定了不同的用户优先级,它也可以忽略此请求并选择其他 BIS,如上所述。

与单播情况不同,广播发送器和接收器独立工作。广播接收器会自行做出决策,但不一定基于广播助手的指令。设计师应该考虑在没有广播助手的情况下,广播接收器如何做出这些决策,以提供一致且合理的用户体验。

12.5 虚拟广播助手

蓝牙 LE audio规范中未使用“虚拟广播助手”这一术语。该术语用于描述与广播音频扫描控制点特性交互,但不支持扫描扩展ADV的设备或应用。

大多数开发者都假设,用户界面有限的耳塞和助听器会使用智能手机作为广播助手来执行扫描并查找广播发射器。然而,这并非唯一的选择。正如我们在 12.4.1 节中看到的,广播接收器不仅可以执行自己的扫描,还应该维护一个数据库,记录其发现的内容,无论扫描由谁执行。该信息数据库保存在一组广播接收状态特性实例中。这些都是 GATT 特性,这意味着任何低功耗蓝牙设备都可以读取和写入它们,无论其是否具备扫描功能。这意味着,老款蓝牙智能手机、笔记本电脑和平板电脑可以通过读取其广播接收器上的广播接收状态实例来控制耳塞或助听器,并将其呈现给用户进行选择,然后将其写入这些广播接收器中的广播音频扫描控制点特性。

在这里插入图片描述

图12.12 虚拟广播助手操作示例

图 12.12 展示了其工作原理。在本例中,左耳塞执行扫描,并将其找到的广播发射器填充到其广播接收状态特性实例中。手机上的虚拟广播助手应用与两个耳塞配对。它不执行扫描,但会读取这些广播接收状态特性并将其显示给用户。当用户点击其中一个条目进行选择时,虚拟广播助手应用会对左右耳塞上的广播音频扫描控制点特性执行“修改源”操作,指示它们与 BIG 中相应的 BIS 同步。(正如我们上面所见,它也可以通过向 BIS-Sync 参数字段写入 0xFFFFFFFF(无偏好)来将 BIS 的选择权留给每个耳塞)。

请注意,只需一只耳塞进行扫描。为了平衡电池续航时间,实现方案可能会选择在两只耳塞之间交替扫描,但这只是实现方案的考量。图 12.12 还展示了虚拟广播助手可以用来控制音量。

图12.13 展示了广播助手和虚拟广播助手之间的区别。顶部的广播助手支持扫描,允许广播接收器委托扫描角色。

在这里插入图片描述

图12.13 广播助手与虚拟广播助手的比较

相比之下,虚拟广播助手依靠来自其他设备的信息来识别广播发射器的存在。这可以通过读取其配对的广播接收器上的广播接收状态特性来实现,或者如图 12.13 所示,通过扫描广播发射器上代表广播音频 URI 的二维码来实现。将这些详细信息写入广播接收器后,每个广播接收器都需要执行扫描才能同步到广播音频流。

Logo

汇聚全球AI编程工具,助力开发者即刻编程。

更多推荐