第 5 章 LC3、延迟和 QoS

 机器翻译，仅用于学习记录，原文链接

5.1 介绍

无线音频最受争议的两个方面是音频质量和延迟，尤其是在发烧友中。在早期，蓝牙技术经常因两者而受到批评，尽管在大多数情况下，音频质量可能更多地与传输音频的传感器的状态有关，而不是与蓝牙实现或规格有关。

通过任何无线连接传输音频都涉及妥协。干扰是生活中的事实，这意味着一些音频数据会丢失。这会导致音频中出现间隙，除非您采取措施添加冗余。通常，这涉及多次传输音频数据包，以便其中一个数据包有多次机会通过。但是，要做到这一点，您必须能够压缩音频，以便您有时间传输多个副本。这是使用 codecs 完成的（codecs 是 coder 和decoder 的合成词）。

打码机接收模拟信号，将其数字化并压缩数字数据，以便在比原始样品长度更短的时间内传输。这意味着在采集下一个样本之前，它可以多次传输。如果第一次传输丢失或损坏，则可以使用以下重新传输来代替它。接收设备中的解码器对接收到的数据进行解码，将其扩展以重新生成原始音频信号。由于执行编码和解码需要时间，这会导致原始信号和解码器传出的重构信号之间出现延迟。

音频编解码器是一项相对较新的发明。从 1860 年代的留声机开始，通过无线电广播、黑胶唱片和磁带进行音频传输的前一百年，都使用原始音频信号。如果受到天气干扰、唱片或蜡筒上的划痕或磁带上的拉伸，则声音会丢失或失真。随着 CD 的推出，这种情况发生了变化，脉冲编码调制 （PCM） 的发展使 CD 成为可能，它将模拟信号转换为数字信号。

PCM 的工作原理是以高于我们能听到的频率（CD 每秒 44,100 次）对音频信号进行采样，并将每个样本转换为数字值。Decoding 反向执行此作，使用数字到音频解码器来恢复模拟信号。每个样本中的位数越多，输出音频就越接近原始输入。CD 和大多数音频编解码器都使用 16 位采样。如果采样率和每个样本的位数足够高，人耳无法检测到差异。但是，纯PCM 数字文件的文件大小很大，因为不涉及压缩。以 44.1kHz 和 16 位采样每秒产生800kbits，因此一首五分钟的单声道歌曲约为 26MB，立体声为 52MB。这就是标准 CD 只能容纳大约一个小时的音乐的原因。

由 Fraunhofer 研究所开发的 MP3 音频编解码器的问世改变了数字音乐的传播方式。它使用一种称为感知编码（有时也称为心理声学建模）的技术，该技术将音频流与人耳实际可以听到的知识进行比较。这可能是高于大多数人可以听到的范围的高频声音，因此可以使用较少的数据进行编码，或者是保持音符，其中编码器可以指示您只需要重复前一个样本或编码与它的不同。通过应用这些方法，可以显著减小数字化音频文件的大小。MP3 编解码器通常会将数字化音乐文件的大小减小 25% 到 95%，具体取决于内容。很少有听众担心这个过程会带来任何轻微的质量损失，他们认为增加的便利性远远超过了对音乐的任何明显影响。

音乐文件大小的减小导致了 Napster 等音乐共享服务的创建以及 MP3 播放器的出现。它还为流媒体服务和无线音频传输的发展打响了发令枪，因为减小的文件大小意味着有足够的时间重新传输压缩的音频数据包，有助于应对传输的任何中断。

5.2 编解码器和延迟

使用编解码器的一个缺点是它们会增加信号的延迟。这是原始模拟信号到达发射器与重构信号在接收器处呈现之间的延迟。

图 5.1 显示了构成该延迟的元素。首先，对音频进行采样。感知编码需要编解码器查看多个连续的样本，因为很多压缩机会来自识别重复声音（或没有声音）的周期。这意味着大多数编解码器需要捕获足够的连续样本，以获得足够的数据来描述这些变化的特征。此采样周期称为帧。不同的编码技术使用不同的帧长度，但几乎总是固定的持续时间。如果太短，则有限的样本数量会开始降低编解码器的效率，因为它没有足够的信息来应用感知编码技术，这会影响质量。另一方面，如果帧大小增加，质量会提高，但延迟会增加，因为编解码器必须等待更长的时间才能收集每一帧音频数据。 

图 5.2 说明了这种权衡。这将因编解码器而异，具体取决于它们执行压缩的方式。对于可用于语音和音乐的编解码器，一般规则是较小的帧大小提供较低的延迟（通常认为这更好，尤其是对于语音和现场音乐），但较大的帧大小会导致更高的质量，因为它们包含更多信息以馈送到心理声学算法中。业界发现，帧长约为 10 毫秒是一个最佳点，它可以在合理的延迟下提供良好的语音和音乐质量。

还有另一个权衡，即运行编解码器所需的处理能力，这称为复杂性。当您尝试从编解码器中挤出更多音频质量时，您通常需要更快的处理器，这开始缩短电池寿命。这在手机或 PC上可能不是问题，但如果您正在对助听器或耳塞的麦克风输入进行编码，那就是一个非常严重的问题。

回到图 5.1 和无线音频传输的一般原则，一旦音频帧被编码，无线电就会将其传输到接收设备。与编码相比，传输通常很快，但如果协议包含重传机会，则需要在开始解码之前考虑这些机会。从第一次传输开始到最后一次接收到的传输结束之间的持续时间称为传输延迟，范围从几毫秒到几十毫秒不等。（您可以在收到第一个数据包后立即开始解码，但如果您这样做，则需要对其进行缓冲。这是因为需要重建输出音频流才能没有间隙，因此必须延迟到每个重传机会都过去，以应对数据包需要最大重传次数才能通过的情况。否则，提前到达的数据包将提前呈现，而其他数据包则不会。

最后，在收到编码的音频数据后，需要对其进行解码，以将其转换回模拟形式以进行渲染。解码通常比编码更快，并且没有帧延迟，因为解码器会自动扩展输出帧。它通常比编码消耗更少的功率，因为大多数编解码器都是为在制作时对文件进行一次编码，然后多次解码（例如从中央服务器流式传输音乐时）的用例而设计的，因此大多数音频编解码器设计都存在固有的不对称性。

5.3 经典蓝牙编解码器 – 它们的优势和局限性

现有的蓝牙音频配置文件都是根据其各自的用例的特定要求开发的，并针对每个用例优化了不同的编解码器，如图 5.3 所示。最初的 HFP 规范旨在使用 CVSD（连续可变斜率增量调制）编码方法，这是一种低延迟编解码器，广泛用于电话应用。

CVSD 是最早数字化和压缩语音的方法之一。它采样速度很快 - 通常以每秒 64000 个样本的速度采样，但仅捕获当前样本与前一个样本之间的差异。这意味着它是无帧的，并且具有相对较短的采样和编码延迟。同样，可以快速执行输出解码。权衡是质量有限，而且由于没有压缩，它实际上是实时的，没有重传的机会。

HFP 的更高版本包括 mSBC - A2DP 中指定的 SBC 编解码器的修改版本，以支持宽带语音。mSBC 实际上是 SBC 的简化版本，对于单个单声道流，采样频率有限。作为基于帧的编解码器，它会增加延迟，导致典型的整体延迟约为 30 毫秒。这些将 HFP 置于图 5.3的低延迟、中低质量象限。 

相比之下，A2DP 专为高品质音乐而设计。它强制要求 SBC（子频段编码）编解码器，这是一种基于帧的编解码器，具有相当基本的心理声学建模。它可以产生非常好的音频质量，与原始音频流相比，这接近有经验的听众可以检测到的极限。A2DP 规范还允许使用由外部公司或标准组开发的替代编解码器——包括 AAC（Apple 在其大多数蓝牙产品中使用）、MP3 和 ATRAC，以及公司使用专有编解码器的选项。其中许多已经流行起来，其中最著名的是高通的 AptX 系列。几乎所有这些编解码器都有更长的延迟。

在图 5.3 中，A2DP 位于图的右上象限，延迟很长。这在一定程度上是由于希望使用重传来尝试使音频更加健壮。虽然听众过去常常接受唱片上的划痕等故障，但他们似乎对音频流中偶尔的 “爆裂” 或丢失的容忍度要低得多。最简单的解决方案是添加更多的重传和缓冲，但这意味着无线音乐流媒体通常有 100 – 200 毫秒的延迟，即使您正在从手机或计算机上的文件流式传输也是如此。尽管编解码器不涉及这种延迟，但知道它发生意味着编解码器设计人员通常不会专注于改善延迟，除非它适用于游戏等特定应用程序。

虽然 100 – 200 毫秒的延迟听起来很过分，但对于大多数音乐应用程序来说，这不是问题。流式传输音乐时，无论是来自音乐播放器还是 Internet 服务，用户都无法指示他们是否在实时收听。只要音乐流在他们按下 Play 按钮后的一秒钟内开始，并且音乐流是连续的，没有烦人的中断，他们就会很高兴。但是，当音频是视频的配乐时，他们可能会注意到口型同步问题，因为在看到某人说话和听到他们的声音之间出现 200 毫秒的延迟看起来是错误的。电话和电视制造商可以通过延迟视频来补偿任何音频延迟来解决此问题。

音频/视频分发传输协议 （AVDTP） 是 A2DP 配置文件的基础，它包含延迟报告功能，该功能允许音频源设备询问接收器音频路径中的延迟是多少。知道这一点，电视和电话可以延迟视频，使声音和图像同步。但是，许多电视和耳塞的音频或视频缓冲内存有限，因此超过几百毫秒的延迟可能会出现问题。

即使是短暂的音频延迟也可能成为一个问题，用户既可以听到蓝牙音频，也可以听到声音的原始环境源。这早已得到助听器行业的认可，用户在剧院中通过感应线圈系统收听现场声音或电影院，但也可以听到环境声音。同样的问题也发生在家里，看电视的家庭包括一些佩戴支持无线传输的助听器的成员，以及一些没有的成员。目前用于这些应用的感应线圈感应线圈是模拟的，因此几乎没有延迟。为了解决这些限制，Bluetooth SIG 需要找到一种编解码器，该编解码器能够覆盖比 SBC 更多的质量/延迟频谱。

当前的 SBC 编解码器存在更多限制，而不仅仅是有限的音频质量和延迟虽然它是相对高效的 SBC，复杂度低，但它占用了太多的通话时间，这会对耳塞的电池寿命产生重大影响。

对于使用小型锌空气电池供电的助听器来说，这是一个问题。这些对峰值电流和接收或传输的电流突发长度都很敏感（蓝牙芯片通常消耗的电流比发射的电流多。如果超过这些电池的工作限制，它们的使用寿命可能会大大缩短。为了解决这些限制，Bluetooth SIG 开始寻找编解码器，从而纳入了新的低复杂度通信编解码器，通常称为 LC3。

蓝牙 LE Audio 允许制造商使用其他编解码器，但 LC3 对所有设备都是强制性的。这样做是为了确保互作性，因为每个 Audio Source 和每个 Audio Sink 都必须支持它。编解码器的完整规范已发布，并属于蓝牙 RANDZ许可，因此任何人都可以编写自己的实现并将其整合到他们的蓝牙产品中，只要这些产品通过蓝牙认证流程即可。考虑到它的质量，这是使用它的强大动力。

5.4 LC3 编解码器

LC3 是当今最先进的音频编解码器之一，提供了极大的灵活性，涵盖了从语音到高质量音频的所有内容。任何人都可以为蓝牙 LE Audio 产品开发自己的 LC3 实现，尽管考虑到编写和优化编解码器的专业性质，很少有人可能这样做。相反，他们将使用来自其芯片或堆栈提供商的实现。因此，我只提供它的作用和工作原理的概述。LC3 规范中有更详细的介绍，以及大约 200 页的规范详细信息，供任何喜欢自己实现的人使用。

LC3 规范是迄今为止最成功的尝试之一，它在单个编解码器中涵盖了无线音频的所有音频质量和延迟要求。它针对 10 毫秒的帧大小进行了优化，预计所有新应用程序，特别是公共广播应用程序，都将使用强制性的 10 毫秒帧。它还使用 7.5 毫秒的帧大小，与以7.5 毫秒间隔运行的蓝牙经典音频应用程序（对应于 EV-3 SCO 数据包）兼容。此外，它还支持扩展的 10.88ms 帧，以提供传统的 44.1kHz 采样。对于需要支持 44.1kHz 的基于 7.5ms 的系统，这降低到 8.163ms。但是，这些是支持旧版或组合蓝牙经典音频/蓝牙LE 音频实现的特定变体。 

表 5.1 再现了 LC3 规范表 3-1 中的关键参数。如果正在传输多个音频通道，则每个通道通常需要一个 LC3 实例。

audio channel 和每个 sampling frequency。例如，以 48kHz 采样传输立体声的广播源需要两个实例。如果它包括一个下混单声道，则需要三个实例，如果它想以 24kHz 和48kHz 采样率传输立体声流，则需要四个实例。

Bluetooth SIG 已委托独立测试实验室进行广泛的音频质量测试，以量化 LC3 编解码器的主观性能。这些结果表明，在所有采样率下，音频质量都超过相同采样率下 SBC 的音频质量，并且以一半的比特率提供同等或更好的音频质量。实际好处是，对于同一音频流，LC3编码数据包的总大小大约是 SBC 数据包大小的一半。实施者可以利用它来发挥自己的优势，因为它减少了传输的总通话时间，节省了电池寿命，或者他们可以使用它来提高音频质量。它为他们提供了更大的参数使用空间，尤其是在耳塞和助听器等功率受限的设备中。省电功能还为耳塞添加了额外的功能，例如更先进的音频算法或生理传感器，同时保持较长的电池寿命。 

5.4.1 LC3 编码器

图 5.5 提供了 LC3 编码器的高级视图。

编码器的第一个元件是 Low Delay Modified Discrete Cosine Transform 模块 （LD-MDCT）。LD-MDCT 是一种在感知音频编码中执行时间到频率转换的成熟方法。它是低延迟的（因此是 LD），但将音频输入样本转换为频谱系数并将相应的能量值分组到频段中仍然需要时间。这是相当一部分编解码器延迟的来源。

LD-MDCT 馈送的模块之一是带宽检测器，它可以检测以前以不同编码速率采样的传入音频信号。它可以检测语音通信中常用的语音带宽，即 NB（窄带：0-4 kHz）、WB（宽带：0-8 kHz）、SSWB（半超宽带：0-12 kHz）、SWB（超宽带：0-16 kHz）和 FB（全频段：0-20 kHz）。如果检测到不匹配，它会向Temporal Noise Shaper （TNS） 和 Noise Level 模块发出信号，以预防并避免将噪声涂抹到任何空的上部频谱中。

LD-MDCT 生成的频率分量的主要路径是进入频谱噪声整形器 （SNS），在那里它们被量化和处理。SNS 的工作是通过塑造量化噪声来最大限度地提高感知音频质量，以便人耳感知到最终的解码输出尽可能接近原始信号。

编码器中的其余模块主要负责控制工件。编解码器最难处理的声音是具有尖锐起音的声音，例如打击乐器。这些瞬态对于编解码器来说是一件很难处理的事情，响板、钟琴和三角形是用于评估编解码器性能的关键测试声音。尖锐的起音瞬态的部分问题在于，总体而言，这些声音显示出相当平坦的频谱。Attack Detector 向 Spectral Noise Shaper 发出它们存在的信号，以便它可以通知 Temporal Noise Shaping 模块 （TNS） 它们的存在。

然后，TNS 会减少并可能消除具有严重瞬变的信号的伪影。下一阶段是确定对量化频谱进行编码所需的位数，这是 Spectral Quantiser 的工作。它可以被认为是一种智能形式的自动增益控制。它还计算出哪些系数可以量化为零，解码器可以将其解释为静音。此过程可能会引入一些编码伪影，这些伪影由 Noise Level 模块解决，使用伪随机噪声生成器来填补任何空白，确保所有内容都设置为解码器的适当水平。

它还使用来自带宽检测器的输入来确保编码信号仅限于有源信号区域。完成后， spectral

coefficient 被熵编码并多路复用到 bitstream中。

结果 bitstream 的另一个组件是 resampled input。以 12.8 kHz 的固定速率执行，通过长期后置滤波器 （LTPF） 传递。对于低比特率，这会降低任何包含音高或音调信息的帧中的编码噪声。Long Term Postfilter （LTPF） 模块通过控制解码器侧基于音高的后置滤波器来感知量化噪声。

编码的 LC3 帧不包含任何计时信息，例如时间戳或序列号。由使用 LC3 的系统来控制数据包的计时。

5.4.2 LC3 解码器

解码器如图 5.6 所示，它基本上是相反的。

带宽信息用于确定哪些系数为零，而 Noise Filling 模型则为带内系数插入信息。Temporal Noise Shaper 和 Spectral Shaper 处理这些，然后 Inverse LD-MDCT 模块将它们转换回时域。然后应用 Long Term Post Filter，使用传输的音高信息来定义滤波器特性。

在解码每个帧的接收数据包之前，如果控制器检测到负载中的任何错误，则会生成坏帧指示标志 （BFI），以及每个通道的负载大小参数。如果设置了 BFI 标志，解码器将跳过数据包，并发出信号，指示应运行数据包丢失隐藏 （PLC） 算法来替换输出音频流中缺失的数据。在解码过程中检测到的任何错误也将触发 PLC。

5.4.3 选择 LC3 参数

从蓝牙 LE Audio 设计的角度来看，大多数开发人员最接近 LC3 规范的是他们在应用程序中用于配置的参数。这些是表 5.1 功能的子集，如表 5.2 所示。 

编码器和解码器上每个样本的位数是本地设置，可能不同。在大多数情况下，它们设置为16。无论选择什么值，内部模块都以 16 位的深度运行。

对于单播流，Acceptor 可以公开它支持的这些值的组合，以及用于特定用例的配置的首选项。发起方从每个 Acceptor 公开的支持值中进行选择，以配置每个音频流。

为了将这些组合限制为合理的组合数量，BAP 为 LC3 编解码器定义了 16 种配置，以帮助推动互作性。这些部分内容在下面的表 5.3 中重现，涵盖 8 kHz 至 48 kHz 的采样频率。这些可以在 BAP 表 3.5（单播服务器）、3.11（单播客户端）、3.12（广播源）和 3.17（广播接收器）中找到。

对于广播源不知道接收设备的广播流，它必须单方面决定它将使用的 LC3 参数。BAP 目前要求每个广播接收器必须能够解码以 16kHz 编码的 40 字节 SDU 和 24kHz 编码的 60 字节 SDU 的 10ms LC3 帧，因此使用这些值的广播源知道其音频流可以由每个蓝牙 LE 音频设备解码。在

通常，16kHz 采样只能用于语音。24kHz 对于音乐来说就足够了。

某些顶级音频配置文件要求支持接收更高质量的编码 LC3 音频流。TMAP 要求支持一系列编解码器配置，这些配置采用 48kHz 采样、7.5ms 和 10ms 帧以及各种比特率。但是，未连接到所有接收设备的广播源无法知道是否可以解码此类流。我们将在本章后面研究对广播设计的影响。

5.4.4 数据包丢失隐藏 （PLC）

无线传输的一个令人讨厌的现实是数据包会丢失。对于与 Wi-Fi 共享 2.4GHz 频谱的蓝牙、婴儿监视器和许多其他无线产品，这通常是干扰的结果。蓝牙规范是最强大的无线电标准之一，它采用自适应跳频来尝试避免任何干扰，但有时仍会丢失数据。如果音频源是手机或 PC，它们也在使用 Wi-Fi 或具有其他蓝牙外围设备，则有时它们也需要优先级，这会导致蓝牙 LE Audio 传输丢失。我们稍后会研究缓解这些问题的方法，但现实情况是，有时数据包会不可挽回地丢失。

不幸的是，在音频流中丢失数据包非常明显，并且会让用户感到烦恼。为了试图隐藏它，已经发展出许多技术。插入沉默通常很烦人，除非它之前恰好有一个沉默或非常安静的时刻。重复前一帧可能会起作用，但如果连续丢失帧，则情况会变得很明显。

为了提供更好的聆听体验，该行业开发了一系列数据包丢失隐藏算法，这些算法试图通过预测最有可能的音频来隐藏丢失的音频。这些与人声配合得非常好，通常与音乐配合得很好，但如果带有或接近起音瞬态的段落丢失，则很难隐藏。LC3 规范包括为匹配 LC3 编解码器而开发的数据包丢失隐藏算法。每当 Bad Frame Indication 标志发出丢失或损坏的帧信号时，或者当解码器检测到内部位错误时，都会应用它。建议始终使用它或其他 PLC算法。

5.5 LC3 延迟

在本章的开头，我们了解了延迟的基础知识，但更详细地了解其组成部分很重要。

图 5.7 说明了 latency 的主要组成部分，显示了它是如何在 Initiator 和 Acceptor 之间建立的。任何基于帧的编解码器都会由于音频采样而施加延迟。对于 10 毫秒的帧长度（蓝牙 LE 音频中的标准帧长度），这考虑了前 10 毫秒的延迟。对传入的音频帧进行采样后，就可以开始编码，对于 LC3，这大约需要 2.5 毫秒，然后它才会有一个完全编码的SDU 向前传递以进行传输。这包括心理声学建模所需的前瞻元素。

该图显示了立即开始的传输。如果接收方在第一次传输时获得有效数据包，则传输延迟可以小于一毫秒，但如果已安排一次或多次重传，则还需要几毫秒才能在同步参考点收到最后一次可能的传输。蓝牙 LE 音频最早可能发生的时间是从该音频帧的第一个采样点开始的 14 毫秒左右，并且是每个 Acceptor 可以开始解码其接收到的数据包的固定时间点。

如果 Initiator 决定使用更长的同步间隔，或者将 FT、BN 或 PTO 参数设置为大于 1，则传输延迟将相应增加。

Synchronization Reference Point 是 Presentation Delay 开始的地方。在此期间，Acceptor 需要解码 LC3 数据包，这需要几毫秒的时间 

LC3 解码器需要几毫秒，然后应用数据包丢失隐藏 （PLC），如果检测到数据包损坏或丢失，则又需要几毫秒。尽管大多数数据包不需要它，但必须为需要运行 PLC 算法的时间分配时间。如果需要完成任何其他音频处理，例如噪声消除或语音增强的算法，则需要在Presentation Delay 结束之前完成这些处理，这是每个 Acceptor 呈现重构的音频流的位置。由于 Basic Audio Profile 要求每个 Acceptor 必须支持 40 毫秒的 Presentation Delay 值，因此它们需要支持大约 40 毫秒的缓冲，以便在渲染点之前保存解码的音频数据。在实践中，Presentation Delay 的值可能更低或更大 – 接收设备的制造商可能支持从 5 毫秒到几百毫秒的范围。

如果一切都经过优化，那么对于一个 10 毫秒的 LC3 数据包，使用非常短的呈现延迟，整个过程的最快时间略低于 20 毫秒。使用 7.5 毫秒的帧几乎没有区别，因为较短的帧需要更长的提前延迟，因此节省的时间仅为 1 毫秒左右。

20 毫秒的延迟相当于声音传播约 7 米所需的时间。我们的听力已经进化到可以应对这种程度的延迟。如果我们在 25 到 30 毫秒后听到原始声音和回声，大脑会毫不费力地处理它。这意味着我们可以将蓝牙 LE Audio Streams 用于耳塞和助听器，它们可以拾取环境声音以及蓝牙流，而不会让佩戴者被任何回声效果分散注意力。但是，上面的示例涉及大量优化。它假设编码完成后就可以开始传输，并且所有重传都发生在帧的四分之一内，这仅对小数据包和较低的采样频率有效。在大多数实际应用中，其他因素也会发挥作用，这让我们想到了服务质量或 QoS。

5.6 服务质量 （QoS）

服务质量是一个术语，适用于接收到的音频信号，包括延迟、解码音频的感知声音以及任何音频伪影的发生率，例如爆裂声、噼啪声和间隙。所有这些功能都相互权衡。上面描述的延迟示例是一个非常理想化的示例，其中数据包在预期时到达。在实践中，他们没有。

人体吸收蓝牙信号的效率非常高，因此如果有人戴着耳塞，但将手机放在牛仔裤的后袋中，手机和耳塞之间的信号可能会衰减高达 80dB。如果您在房间里，这可能无关紧要，因为耳塞可能会接收到来自墙壁或天花板的反射信号。但是，如果您在室外，没有那些反射表面，则会丢失更多的数据包。

在上一章中，我们看到 Isochronous Channels 的设计通过使用重传、预传输、突发编号、flush 超时和跳频来增加健壮性。如果我们应用足够多的这些功能，我们就有非常高的信心，几乎每个数据包都会通过，而没有完好无损地到达的少量数据包可以使用 PLC 填充。然而，当我们应用这些技术时，延迟开始增加，功耗也开始增加消费。将重传分散到多个 Isochronous Interval 会为每个额外的 Isochronous

Interval 的延迟增加额外的帧时间。在单个帧中放置更多的重传会限制可以容纳的不同流的数量，并推高功率 - 无论是对于发射器还是接收器，都需要保持活动状态以寻找连续的传输时隙。

这些稳健性功能与编解码器设置是分开的。但编解码器设置也会影响稳健性。具有 48kHz采样的更高质量编码将产生更大的数据包，这些数据包将更容易受到干扰。同样，如果将多个蓝牙 LE 音频流编码为单个数据包，即通道分配大于 1，则该 SDU 将包含多个编解码器帧，从而导致更大的数据包，并出现相同的问题。

鉴于可能进行大量可能的编解码器和稳健性配置，BAP 针对两个主要用例（低延迟和高可靠性）定义了一组标准组合，这些组合可以在 BAP 的表 5.2 和 6.4 中找到。它们涵盖10 毫秒和 7.5 毫秒的帧间隔。术语 高可靠性 有时会被误解。在这些表中，它表示稳健性有所提高，其中延迟放宽以允许更多重新传输。

Low latency 被解释为允许所有重传都适合 8kHz 至 32kHz 采样率的单个同步间隔的设置。48kHz 的较大数据包扩展为两个同步间隔，44.1kHz 最多扩展为四个同步间隔。高可靠性 QoS 配置优先考虑重传而不是延迟，允许重传分布在 6 个或更多同步间隔（广播）和 10 个或更多（单播）中。术语 High Reliability 可能更适合解释为 High Robustness。由于重新传输的次数较多，因此也会导致更高的延迟。

表 5.4 显示了从这些表中得出的每个采样频率允许的最大同步间隔数。Low Latency 48 kHz sampled （低延迟 48 kHz 采样） 设置需要两个 Isochronous Intervals（同步间隔）的原因是允许使用较大的数据包进行足够数量的重传，因为只有有限数量的数据包适合单个 Isochronous Interval（同步间隔）。对于低采样频率，较小的数据包意味着每个同步间隔可以容纳更多的重传。分配多少次重传最终取决于 Controller 中的调度程序。 

在图 5.7 的延迟示例中，我们看到使用具有 10ms 帧和显着优化程度的 LC3 时，整体延迟约为 20ms。这使用了略高于 5 毫秒的 Presentation Delay。如果低延迟对应用程序很重要，则实施者需要谨慎选择 QoS 和编解码器配置，因为这可能会导致延迟显著增加。表5.5 显示了可能实现的典型总体延迟值。这些是使用 LC3 采样和编码 10ms 帧的 12.5ms 值计算得出的。 

表 5.5 中的值适用于单个单声道音频流。正如我们将看到的，对于立体声应用程序，延迟会增加。给实现者的信息是在选择编解码器时要小心和 QoS 设置。

BAP 表 5.2 和 6.4 中的服务质量建议包括对 HCI 命令中用于设置单播或广播流的参数的建议。这些建议（请记住，控制者使用其中一些建议作为指导，而不是作为确定性值）涵盖：

• SDU 间隔（与帧持续时间相同，但 44.1kHz 除外）
• 成帧要求（除 44.1kHz外，所有都是无帧的（ 44.1kHz 是成帧的）
• Maximum_SDU_Size（与Supported_Octets_per_Codec_Frame相同）
• 低延迟和高可靠性选项的推荐重传数 （RTN）
• 低延迟和高可靠性选项的Max_Transport_Latency， 和
• Presentation Delay，要求 40ms 的值在支持的范围内。

使用这些表中的值可能并不总是产生预期的延迟。原因之一是 Presentation Delay 的值。BAP 要求所有 Audio Sink 在其支持的值范围内包含 40ms 的 Presentation Delay，但不应将其视为默认值 - 这是表格底部的注释中所说的 - 每个充当 Audio Sink的 Acceptor 都必须支持该值。这是对互作性的妥协，以确保一切都有时间解码音频数据、应用 PLC 和任何其他处理。大多数设备将能够做得更好。表中的 40ms 值代表了2020 年写入 BAP 时原型中预期的最坏情况。从那时起，更高层的轮廓需要更严格的性能。TMAP 和 HAP 都要求 Acceptor 支持 20 毫秒的广播呈现延迟，但如果 Initiator将其设置为 40 毫秒，则会影响延迟。GMAP 施加了总体延迟要求，这些要求需要类似的 值。大多数当前设备可以支持大约 10 毫秒的值，尽管一些复杂的音频处理算法可能需要更长的时间。

回想一下图 5.7，该示例中的 Presentation Delay 只有 5ms 左右，导致整体延迟低于25ms。许多设备将能够支持这一点，但它是高度优化的。在单播中，发起方和接受方相互通信时，当发起方意识到它正在提供低延迟用例时，他们可以就较低的 Presentation Delay （表示延迟） 值达成一致。

相比之下，广播源无法了解其周围的广播接收器的功能，因此必须根据用例和对广播接收器功能的了解做出决策，这些广播接收器在市场上以及其设计人员希望能够访问它。HAP和 TMAP 都要求兼容设备能够支持 20ms 的演示延迟，因此这是一个安全的选择。如果需要尽可能低的延迟，广播源可以包含额外的 LTV 结构，即广播音频即时渲染标志，该标志在分配编号文档中定义。这会告诉 Acceptor 它可以忽略 BASE 中的 Presentation Delay 值，并在需要时立即呈现音频流。当它决定渲染时，它完全取决于实现。如果它是 Coordinated Set 的成员，则两个设备需要某种方式来通知彼此它们将使用的 Presentation Delay 的本地值，以确保渲染的音频同步。他们如何做到这一点超出了蓝牙 LE Audio 规范的范围，有待实现。

回到表 5.5 中的 Low Latency 列，当用于环境声应用时，高于 32 kHz 的采样频率可能会产生回声效果。在增强环境声音时，尤其是对于广播，任何 High Reliability（高可靠性）设置都不是真正适合的。在实时环境中，很少有用户能够注意到 32kHz 和 48kHz 采样之间的音频质量差异，但他们会注意到延迟的差异。

在无法听到环境音频流的情况下（大多数流式音乐和电话应用程序都是这种情况），延迟问题要小得多，除非有伴随的视频流，这可能会导致口型同步问题。但是，在这些情况下，视频应用程序通常会管理音频流，因此可以调整相对计时以防止出现任何问题。

RTN – 重传号码，从一些进一步的解释中受益。某些配置中的较大值表示大量重传，但情况并非如此。RTN 在 BluetoothCore 规范 [第 4 卷，E 部分，第 7.8.97 节] 中定义为CIS 数据 PDU 在刷新之前应从中央重新传输到外围设备或从外围设备重新传输到中央的次数。（两个方向可能不同。对于广播，它只是 PDU 被重传的次数 [第 4 卷，E 部分，第7.8.103 节]。正如我们已经看到的，不允许 Host 指定 FT、PTO、NSE 或 BN 的值，因为它不知道 Controller 可能具有哪些其他约束。因此，RTN 只是一个帮助指导 Controller的调度算法的建议。

大多数情况下，单播音频数据不会传输 RTN 次。如果 SDU 的 FT 大于 1，并且 SDU 传输了最大次数 （RTN + 1），则后续 SDU 将只有 1 次传输机会，无法重新传输。RTN 提供了获得更多传输槽以适应短时间干扰的机会，但将其设置得太高可能会对后续的 SDU 造成不利影响。传输机会的平均数量始终为 NSE/BN。指出这一点后，BAP 表 5.3 和 6.4 中给出的值已经过充分测试，通常应遵循。

但是，如 BAP 的表 6.5 所示，控制器可以选择其他值。

回到 Isochronous Channel 设置，查看 Initiator 的 Host 请求的内容和实际得到的内容非常有用。BAP 提供了一个示例，说明 Controller 如何根据不同的资源约束来解释它收到的 HCI 参数。要了解这种影响，我们可以查看 48_2_2 广播音频流 QoS 配置的 High Reliability （高可靠性） 设置。这在 BAP 的表 6.4 中定义，并在下面的表 5.6 中重现，其中要求的最大传输延迟为 65 毫秒。 

BAP 的表 6.5 提供了建议的链路层参数，供控制器在收到包含表 5.6 值的LE_Set_CIG_Parameters HCI 命令时使用。这些如表 5.7 所示，其中还显示了产生的传输延迟和用于每组参数的可用通话时间的百分比。

 表 5.7 中的三个选项是可能的，因为 Max_Transport_Latency 和 RTN 只是指导Controller 进行调度的建议。根据它正在执行的其他作，它通常需要考虑其他约束。表5.7 中的三个选项是针对以下三种情况的推荐链接层设置：

• 选项 1 具有最低的通话时间，经过优化，可与 Wi-Fi 和其他以 7.5ms 计划运行的蓝牙设备共存。使用更大的同步间隔来承载多个 10ms 帧，为 Wi-Fi作提供最大的间隙。如果广播源是手机或 PC，并且正在使用 Wi-Fi 获取音乐流以通过蓝牙 LEAudio 发送，这非常重要。此选项对蓝牙 LE Audio 传输使用的通话时间最短，但延迟最高。
• 选项 2 旨在提供最高的可靠性和最低的延迟，最大限度地提高每帧中的重传次数。它使用最多的通话时间，因此只真正适用于没有其他 2.4GHz 无线电作的广播设备。
• 选项 3 旨在实现可靠性和共存之间的平衡。对于使用 Wi-Fi 获取音乐流但没有其他共存问题需要处理的广播源来说，这将是一个不错的选择。

这些只是芯片调度程序可以选择的众多可能组合中的三种。随着时间的推移，随着该行业在蓝牙 LE Audio 方面获得了更多经验，其他产品可能会被添加到推荐列表中。

在结束本主题之前，表 5.8 显示了使用这三个选项的立体声广播流的总体延迟，其中TMAP 规定的 Presentation Delay 为 20ms，并且TMAP 和 HAP 规定的呈现延迟为 20 毫秒，BAP 的基线为 40 毫秒。Controller 将通知Host 它选择了哪些参数，但 Host 无法控制该选择的内容。这将取决于芯片中的调度算法。设计人员应该注意这种变化。如果您的应用程序的延迟很严重，请向您的芯片制造商询问他们在 Controller 调度中所做的选择的详细信息。

5.6.1 通话时间和重传

我们在表 5.7 中谈到了通话时间。尽管 LC3 编解码器比以前的蓝牙编解码器更高效，但随着比特率的增加，数据包占用的可用通话时间会越来越多。选项 2 的表 5.7 中的数字显示，使用这些参数的立体声流几乎占可用播放时间的 60%。这不包括广告、其他活跃的蓝牙链接或任何其他 2.4GHz 无线电活动所需的通话时间。

图 5.8 显示了 QoS 配置中较高比特率（使用 10ms 帧大小）的影响，以及 High Reliability （高可靠性） 设置指定的更多重传的影响。对于 48kHz 采样配置，低延迟和高可靠性的通话时间相同，因为建议每个配置的最小重传次数为 4，因为较大的数据包更容易受到干扰。

广播源不知道是否收到了他们的重传，因此必须传输每个数据包。单播发起方仅在无法收到确认时才需要重新传输数据包。这意味着在许多情况下，单播 Initiator 将传输的数据包要少得多，从而为设备上需要它的任何其他资源提供额外的通话时间。但是，如果连接的链接预算很差，例如耳塞和助听器等设备，尤其是在户外使用时，它们可能需要传输最大数量的重传，因此必须为这种可能性分配通话时间。

通话时间是一种有限的资源，提高流的音频质量和可靠性会侵蚀它。蓝牙 LE Audio 的设计要求之一是能够支持多个蓝牙 LE Audio 流，允许电视或电影院传输多种语言的音轨。

从图 5.8 可以看出，除非使用多个无线电来传输每个不同的立体声语言流，否则任何48kHz 采样配置都是不可能的。相比之下，低延迟 24kHz 或 32kHz 配置可以轻松处理两种不同的立体声流。如果产品设计人员想要利用蓝牙 LE Audio 传输多个流的能力，他们需要考虑对通话时间的影响。这给我们带来了音频质量。

5.7 音频质量

自电子音频再现的早期以来，一小群用户一直在追求更高的质量。这导致了录音和复制的技术进步，以及 Hi-Fi 等术语的营销。除了真正的技术进步外，它还看到了伪科学时尚的出现，例如无氧铜电缆和镀金连接器，以“确保”模拟信号不会降级。数字技术并没有减少人们对这些的热情，尽管镀金 USB 连接器已经过时了。音频爱好者一直呼吁提高质量，随着数字时代的到来，人们呼吁更高的采样率、无损编解码器、更高的输出电平，甚至回归电子管放大器。事实上，许多 30 岁以上的人现在都有一定程度的听力损失，这意味着他们无法听到任何这些 “改进” ，但这并不能阻止产品营销经理推动更高的音频质量。

在早期，蓝牙音频吸引了相当多的负面报道。有些是当之无愧的，因为一些 A2DP 头戴式设备具有资源受限的编解码器实现。用于渲染音频的换能器也相对原始。从那时起，随着耳机、耳塞和扬声器的大规模发展，情况发生了很大变化，以至于很少有用户担心蓝牙技术作为音频解决方案，并且它通常用于价值数千美元的高端音频设备。

在 LC3 编解码器开发期间，Bluetooth SIG 委托独立研究其音频质量与其他编解码器的比较。结果证实，它提供等效的或者在 8kHz 到 48kHz 采样的整个频谱中比其他编解码器具有更好的主观性能。LC3 编码的音频流示例可在 Bluetooth SIG 网站上收听，LC3 白皮书中汇编了主观聆听测试结果。

这些测试由一组专业听众在音频收听室中使用高质量的有线耳机进行。他们被要求根据参考录音对每个声音样本进行评分，对他们认为它与原始声音的接近程度进行评分。测试使用了 MUSHRA 协议，混合了 EBU 最测记录的声音。

像这样在完美的聆听条件下完成的测试结果与现实世界的经验总是很难联系起来，因为它们是主观的。但是，我试图在表 5.9 中描述不同 LC3 采样频率的一般应用。 

重要的是，音频应用程序设计人员要明白，在设计无线音频体验时存在妥协，并且选择最高QoS 选项可能会排除新用例的开发。音频行业的一些部分认为他们必须使用 LC3 提供的更高质量并促进最高的采样率，尽管复制和聆听环境的限制可能会意味着很少有听众会欣赏它们。此外，由此产生的延迟可能不适合实时应用程序，并且某些设备可能无法对其进行解码。其他人将查看蓝牙 LE Audio 支持的新功能和用例，并选择 24kHz 或 32kHz 作为可接受的折衷方案，以便开发新的用例。只有时间才能决定用户最看重什么。这可能是他们的应用程序更灵活，或者希望在营销文献中看到更大的 “质量” 数字。

过去，音频行业曾两次决定降低音频质量。首先是 CD 的引入。第二个是使用 MP3，它支持音频流。每一次，在更高的易用性与保持当前的音频质量之间都存在平衡。在这两个场合，消费者都表示压倒性地偏爱易用性而不是音频质量，尽管极少数发烧友对此表示抗议。随着 Auracast™ 体验的推出，我们可能会看到这种情况重演。

5.8 多声道 LC3 音频和音频配置

在第 3 章中，我们介绍了 Audio Channel Allocation 和 Multiplexing 的概念。这意味着在设备之间传输相同的音频数据有多种不同的方式。要了解它们的工作原理，最好看几个例子。在每种类型中，使用以下命名法来描述如何将音频通道多路复用到 CIS 或 BIS 中。

在本节的图表中，每个 CIS 或 BIS 上的箭头数对应于它所承载的音频通道数。为了明确起见，双箭头表示 CIS 携带具有两个编解码器帧（例如 left 和 right）的数据包。 

在我们开始之前，我们需要介绍另一个新功能，即 Audio Configurations。

5.8.1 音频配置

蓝牙 LE Audio 的拓扑结构非常灵活，发起方和接收端都能够支持多个同步通道，每个通道包含一个或多个编码音频渠道。对于单播应用程序，Initiator 应该能够确定 Acceptor 可以支持什么，并确定如何最好地设置其连接。但是，这存在 Initiators 和 Acceptor 的设计人员可能会做出相互冲突的 implementation 决策的风险，这可能会导致不兼容。为了避免这种情况，BAP在 Initiator 和一个或多个 Acceptor 之间定义了 14 种常见的音频配置。它强制要求支持其中一些，并对其他 API 应用进一步的有条件和可选要求。

表 5.10 显示了 Initiator 和单个 Acceptor 之间的连接要求。“M”表示它们是强制性的，并且必须由蓝牙 LE Audio 兼容设备支持。“C” 是有条件的支持，通常基于设备是支持多路复用还是双向 CIS。“O” 表示支持是可选的。这些要求的完整细节，包括条件要求是什么，可以在 BAP 的表 4.2 和 4.24 中找到。

TMAP 和 GMAP 引入并强制要求支持其他音频配置。

Audio Configurations 的目的是允许更高级别的配置文件提高 Initiator 和 Acceptor必须支持的标准，确保它们能够支持更复杂的用例。这并不意味着必须使用这些配置，但符合这些配置文件条件的发起方必须能够在强制的单播客户端音频配置中工作（如果其主机应用程序请求），并且如果单播客户端请求，单播服务器必须能够执行相同的作。

音频配置 6 到 9 以及 11 涉及两个 CIS，以便发起方支持两个接收器。在表 5.10 中，它们带有后缀 （i），表示它们指的是每个流涉及单个 Acceptor 的用例，其中Initiator 支持两个 CIS。 

请注意，Broadcast Transmitter 无法知道 Acceptor 支持什么。因此，应谨慎使用传输两个多路复用编码音频通道的 Audio Configuration 14，因为 Acceptor 不需要支持它。不建议用于任何公共广播应用程序。

表 5.11 显示了 Initiator 使用一对 Acceptor 建立 CIe 的要求，每个 Acceptor 连接一个 CIS。这些用后缀 （ii） 表示。

在表 5.11 中没有 unicast Acceptor 的条目。这是因为 Acceptor 不需要知道任何其他Acceptor 的存在。就它们如何配置为接受 CIS 而言，它们独立运行。因此，就音频配置而言，它们表现为独立的设备，在表 5.11 的音频配置中配置为支持音频配置 1、2 或3。这在 BAP 1.0.2 及更高版本中得到了认可。

许多其他组合是可能的，但蓝牙 LE Audio 设备只能期望存在表示为强制性的组合。发起人可以从 PAC 记录中确定对其他音频配置的支持，并Additional_ASE_Parameters Codec_Specific_Configurations 中的值。

回到多路复用音频流的主题，图 5.10 显示了使用音频配置 2 和 6（ii） 在 Initiator和单个 Acceptor 之间传输立体声流的两种可能选项，该接收器可以呈现立体声音频。这是将音乐从手机流式传输到耳机或从电视流式传输到条形音箱的简单单播用例。 

在图 5.10 的顶部，选项 （a） 使用两个独立的 CIS，一个承载左音频通道，另一个承载右通道。在此之下，选项 （b） 将 Channel Allocation 设置为 2，以便控制器将两个LC3 编码器输出多路复用为单个有效载荷，该有效载荷在单个 CIS 中发送。在 Acceptor处，单独的左右有效载荷在 Controller 中被分离，在 Presentation Delay 之后解码并渲染为单独的通道。编码数据包的多路复用和解复用可以在主机或控制器中执行。这取决于实施。

当我们看一对 Acceptor（例如一组左右耳塞）时，这个例子会变得稍微复杂一些，如图5.11 所示。在顶部示例 （a） 中，这是 BAP 中 Acceptor 的强制性方案之一，Initiator 将每个 Acceptor 配置为接收单个 CIS，该 CIS 仅包含每个 CIS 所需的编码音频。由于每个耳塞只会显示 Front Left 或 Front Right 的单个 Sink Audio 位置，因此 Initiator 知道要向每个耳塞发送哪些内容。 

在下面的示例 （b） 中，发起方还为每个 Acceptor 设置一个 CIS，但在这种情况下，将多路复用的立体声流发送到每个接受器。为了允许此配置，每个 Acceptor 必须公开一个Sink Audio Locations 特征值，该值同时支持 Front Left 和 Front Right。每个Acceptor 将解码多路复用的数据包并丢弃不相关的音频数据。请注意，这些是此安排的未定义 Audio Configuration，并且接收多路复用流的能力对于 Acceptor 不是必需的。因此，选择此选项不仅在通话时间使用方面不理想，而且可能无法互作。

将相同的单播立体声输入发送到单声道 Acceptor 更有趣一些，因为在输入和输出之间的某个点，需要将立体声信号下混为单个单声道流。有三种可能的方法可以做到这一点，如图 5.12 所示。 

对于选项 （a），Acceptor 会将其 Audio Sink Location 设置为 Mono。这要求Initiator 在执行 LC3 编码之前对其立体声输入进行缩混，这超出了蓝牙 LE Audio 规范。此配置可以最佳地利用通话时间，并且可以与任何充当 Audio Sink 的 Acceptor 互作。

对于选项 （b） 和 （c），需要将 Acceptors 的 Sink Audio Locations 特性设置为Front Left 加上 Front Right，因此其 Supported Sink Audio Locations 值将为0x0000000000000011。这可确保 Acceptor 接收到两个音频声道，以便它可以执行缩混。

每个 Initiator 都可以支持选项 （b），但不会意识到其立体声流正在呈现为 mono。

在选项 （b） 和选项 （c） 中，Acceptor 在编解码器配置过程中显示的 Channel Allocation（通道分配）和 Audio Sink Location（音频接收器位置）信息与如果Acceptor 是立体声设备时所设置的信息相同（参见图 5.10）。这意味着 Initiator 无法知道它是在渲染单声道还是立体声装置。因此，它为其提供立体声信息，要么在选项（b） 中作为两个单独的 CIS，要么在选项 （c） 中作为单个 CIS 上的多路复用流。在这两种情况下， Acceptor 都负责对生成的流进行下混。这可以在 Acceptor 上配置，可能通过简单的 switch 进行配置，但 Initiator 并不知道。值得注意的是，规格书中没有涵盖这三种组合。发起方是否可以将立体声下混为单声道超出了蓝牙规范的范围，并且当

Acceptor 只能呈现一个流时，要求它支持两个 CISes 不是必需的。建议打算渲染 mono 的Acceptor 的设计者至少支持选项 （a） 和 （b）。发起方和接受方都不需要支持多路复用音频配置 （c），但支持它的发起方可以确定接受方是否支持它，如果不支持，则可以恢复为选项（b）。

5.9 其他编解码器

LC3 是一个非常好的编解码器，可以在语音和音乐应用的广泛采样率范围内使用。每个蓝牙 LE Audio 设备都必须以 16kHz 和 24kHz 采样率支持它（发起方只需要支持 16kHz，因为某些公共广播系统可能仅支持语音），但大多数实现可能支持更高的采样频率。尽管如此，其他编解码器可能会在一些专门的应用程序中表现得更好。为了适应这一点，蓝牙 LE 音频规范允许使用其他编解码器或供应商特定的编解码器。 

其他编解码器过去在 A2DP 中称为可选编解码器。这些编解码器是由外部规范机构或公司设计的，但蓝牙规范包括配置信息，允许合格的设备识别它们的存在以及如何设置它们。

这允许多个制造商添加使用它们的能力，因为他们知道它们将协同工作。否则，连接将默认恢复为强制 Bluetooth 编解码器。通常，其他编解码器可以从外部标准组织或专业公司获得许可，因此任何人都可以将它们集成到他们的产品中。目前，没有为蓝牙 LE Audio 定义额外的编解码器，但几乎可以肯定的是，这种情况会随着时间的推移而改变，就像 A2DP 一样。

供应商特定的编解码器是由制造商许可的编解码器，制造商向其被许可方提供 Bluetooth配置信息。其他蓝牙产品无法理解该信息，因此会忽略它们并使用强制编解码器或其他编解码器（如果支持）。供应商编解码器是专有的，不在 Bluetooth 规范的范围内。在使用它们的位置，Codec_ID 设置为 Vendor Specific。