第5章-LC3, latency and QoS

大家好，欢迎来到IT知识分享网。

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

5.1 简介

无线音频（尤其是在有声读物中）最受争议的两个方面是音频质量和延迟。在早期，蓝牙技术经常因两者而受到批评，尽管在大多数情况下，音频质量可能更多地与渲染音频的换能器的状态有关，而不是与蓝牙spec有关。

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

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

音频编解码器是相对较新的发明。从 1860 年代的留声机到无线电广播、黑胶唱片和磁带，最初的一百年音频传输都使用原始音频信号。如果有天气干扰、唱片或蜡缸上的划痕或磁带上的拉伸，声音就会丢失或失真。随着 CD 的推出，这种情况发生了变化，这得益于脉冲编码调制 (PCM) 的发展，它将模拟信号转换为数字信号。

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

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

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

5.2 编解码器和延迟

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

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

图 5.2 说明了这种权衡。这将因编解码器而异，具体取决于它们执行压缩的方式，但对于可用于语音和音乐的通用编解码器，业界发现帧长度约为 10 毫秒的最佳位置，以合理的延迟提供良好的质量。

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

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

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

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

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

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

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

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

虽然 100 – 200 毫秒的延迟听起来有点过分，但对于大多数音乐应用程序来说这不是问题。在流式传输音乐时，无论是来自音乐播放器还是互联网服务，用户都无法表明他们是否在实时收听。只要音乐流在他们按下播放按钮的一秒钟内开始，并且音乐流是连续的，没有烦人的中断，他们就会很开心。但是，当音频是视频的配乐时，他们可能会注意到口型同步问题，因为看到某人说话和听到他们的声音之间的 200 毫秒延迟看起来不对。电话和电视制造商可以通过延迟视频来补偿任何音频延迟来解决这个问题。作为 A2DP profile基础的音频/视频分发传输协议 (AVDTP) 包含延迟报告功能，该功能允许音频源设备向接收器询问音频路径中的延迟时间。知道了这一点，电视和手机可以延迟视频，使声音和画面同步。但是，许多电视和耳塞的音频或视频缓冲内存有限，因此几百毫秒以上的延迟可能会出现问题。

在LE audio 开发过程中，很明显当前的蓝牙编解码器难以满足要求。它们不仅在质量和延迟权衡方面受到限制，而且 SBC 的效率不如耳塞和助听器设计者所希望的那样。它的复杂性相对较低，但占用的空中传输时间过多，这对耳塞的电池寿命有很大影响。对于使用小型锌空气电池运行的助听器来说，这是一个问题。它们对峰值电流和接收或传输的电流突发长度都很敏感（蓝牙芯片通常会消耗更多的电流接收而不是传输。）如果这些电池超过工作限制，它们的寿命可能会大大缩短。为了解决这些限制，Bluetooth SIG 进行了编解码器搜索，最终纳入了 LC3。

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

5.4 LC3编解码器

LC3 是当今最先进的音频编解码器之一，提供了极大的灵活性并涵盖了从语音到高质量音频的所有内容。任何人都可以为LE audio 产品开发自己的 LC3 实现，尽管鉴于编写和优化编解码器的特殊性质，很少有人可能这样做。因此，我只会概述它的作用和工作原理。

LC3 spec中有更详细的介绍，还有大约 200 页的spec细节供任何想自己实现的人使用。

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

表 5.1 再现了 LC3 spec表 3-1 中的关键参数。

蓝牙 SIG 已委托独立测试实验室进行广泛的音频质量测试，以量化 LC3 编解码器的主观性能。这些表明，在所有采样率下，音频质量都超过了相同采样率下的 SBC，并以比特率的一半提供同等或更好的音频质量。实际的好处是 LC3 编码数据包的总大小约为 SBC 相同音频流大小的一半。

实施者可以利用它来发挥自己的优势，因为它可以减少传输的总空中传输时间，节省电池寿命，或者他们可以使用它来提高音频质量。它为他们提供了更多使用参数的空间，尤其是在耳塞和助听器等功率受限的设备中。省电还允许在耳塞中添加额外功能，例如更高级的音频算法或生理传感器，同时保持较长的电池寿命。

5.4.1 LC3编码器

编码器的第一个元素是低延迟修正离散余弦变换模块 (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）。如果它检测到不匹配，它会向时间噪声整形器 (TNS) 和噪声电平模块发出信号，以防止并避免任何噪声拖入任何空的上频谱。

LD-MDCT 生成的频率分量的主要路径是进入频谱噪声整形器 (SNS)，在那里它们被量化和处理。 SNS 的工作是通过对量化噪声进行整形来最大化感知音频质量，从而使人耳感知到的最终解码输出尽可能接近原始信号。

编码器中的其余模块主要负责控制伪影。编解码器最难处理的声音是具有尖锐起音的声音，例如打击乐器。这些瞬变对于编解码器来说是一件很难处理的事情，响板、钟琴和三角是用于评估编解码器性能的关键测试声音。尖锐的起音瞬变的部分问题在于，总体而言，这些声音显示出相当平坦的频谱。攻击检测器向频谱噪声整形器发出它们的存在信号，以便它可以通知时间噪声整形模块（TNS）它们的存在。然后，TNS 减少并可能消除具有严重瞬态的信号的伪影。

下一阶段是确定编码量化频谱所需的比特数，这是频谱量化器的工作。它可以被认为是一种自动增益控制的智能形式。它还计算出哪些系数可以量化为零，解码器可以将其解释为静音。此过程可能会引入一些编码伪影，这些伪影由噪声级别模块解决，使用伪随机噪声生成器来填补任何空白，确保所有内容都设置为解码器的适当级别。它还使用来自带宽检测器的输入来确保将编码信号限制在有效信号区域。一旦完成，频谱系数将被熵编码并复用到比特流中。

生成的比特流的另一个组成部分是重采样输入。以 12.8 kHz 的固定速率执行，通过长期后置滤波器 (LPTF)。对于低比特率，这会减少包含音高或音调信息的任何帧中的编码噪声。长期后置滤波器 (LTPF) 模块通过控制解码器端基于音高的后置滤波器，在感知上塑造量化噪声。

编码的 LC3 帧不包含任何时间信息，例如时间戳或序列号。使用 LC3 来控制数据包的时间取决于系统，我们在查看 Core 时看到了这一点。

5.4.2 LC3解码器

带宽信息用于确定哪些系数为零，噪声填充模型为带内系数插入信息。时间噪声整形器和频谱整形器处理这些，然后反向 LD-MDCT 模块将它们转换回时域。然后应用长期后置滤波器，使用传输的音高信息来定义滤波器特性。

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

5.4.3 选择 LC3 参数

从LE audio 设计的角度来看，大多数开发人员最接近 LC3 spec的是他们在应用程序中用于配置它的参数。这些是表 5.1 的特征的子集，如表 5.2 所示。

编码器和解码器的每个样本的位数是本地设置，可能不同。在大多数情况下，它们设置为 16。

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

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

一些顶层音频profile要求支持接收更高质量的编码 LC3 音频流。 TMAP 要求支持使用 48kHz 采样、7.5ms 和 10ms 帧以及各种比特率的一系列编解码器配置。但是，没有连接到所有接收设备的广播源无法知道这样的流是否可以被解码。我们将在本章后面讨论广播设计的含义。

5.4.4 丢包隐匿点（PLC）

无线传输的一个恼人特性是数据包丢失。对于与 Wi-Fi、婴儿监视器和许多其他无线产品共享 2.4GHz 频谱的蓝牙，这通常是由于干扰造成的。蓝牙spec是最强大的无线电标准之一，采用自适应跳频来尝试避免任何干扰，但有时会丢失数据。如果音频源是同时使用 Wi-Fi 或具有其他蓝牙外围设备的手机或 PC，也会有需要优先级的情况，这会导致LE audio 传输丢失。稍后我们将研究减轻这些问题的方法，但现实情况是，有时数据包会丢失且无法挽回。

不幸的是，在音频流中丢失数据包是非常明显的，并且会惹恼用户。为了试图隐藏它，已经发展了许多技术。插入沉默通常很烦人，除非它之前恰好是一个沉默或非常安静的时刻。

重复前一帧可能会起作用，但如果有连续丢失的帧，就会变得很明显。

为了提供更好的聆听体验，业界开发了一系列丢包隐藏算法，这些算法试图通过预测丢失的音频来隐藏丢失的音频。这些对人声非常有效，通常对音乐也非常有效，尽管如果丢失了具有或接近于起音瞬态的片段，则很难隐藏。 LC3 spec包括已开发用于匹配 LC3 编解码器的丢包隐藏算法。每当坏帧指示标志指示丢失或损坏的帧，或者当解码器检测到内部位错误时，都会应用它。建议始终使用它或替代的 PLC 算法。

5.5 LC3 延迟

该图显示传输立即开始。如果接收方在第一次传输时收到有效数据包，则传输延迟可能小于一毫秒，但如果已安排一次或多次重传，则在同步时接收到最后一次可能的传输将需要几毫秒参照点。LE audio 可能发生的最早时间是从该音频帧的第一个采样点开始大约 14 毫秒，并且是每个接收器可以开始解码其接收到的数据包的固定时间点。同步参考点是Presentation Delay开始的地方。在此期间，Acceptor 需要对 LC3 数据包进行解码，这对 LC3 解码器来说需要几毫秒，如果需要，则应用丢包隐藏，这需要另外几毫秒。尽管大多数数据包不需要它，但必须为需要它的场合分配运行算法的时间。如果需要进行任何其他音频处理，例如噪声消除或语音增强算法，则需要在 Presentation Delay 结束之前完成，这是每个 Acceptor 呈现重构音频流的地方。因为 Basic Audio Profile 要求每个 Acceptor 必须支持 40ms 的 Presentation Delay 值，所以它们需要支持大约 40ms 的缓冲来保存渲染点之前的解码音频数据。在实践中，Presentation Delay 的值可能更低或更高——接收设备制造商可能支持低至 5 毫秒到数百毫秒的范围。

如果一切都进行了优化，那么对于一个 10 毫秒的 LC3 数据包来说，整个过程最快的时间就是 20 毫秒多一点。使用 7.5 毫秒的帧几乎没有什么区别，因为较短的帧需要较长的前瞻延迟，因此节省的时间仅为 1 毫秒左右。

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

5.6 服务质量（QoS）

服务质量是适用于接收到的音频信号的术语，包括延迟、解码音频的感知声音以及任何音频伪影的发生率，例如爆裂声、噼啪声和间隙。所有这些功能都相互权衡。上面描述的延迟示例是一个高度理想化的示例，其中数据包按预期到达。在实践中，他们没有。人体对蓝牙信号的吸收效率很高，所以如果有人戴着耳塞，但将手机放在牛仔裤的后兜里，手机和耳塞之间的信号可能会衰减高达 80dB。如果你在房间里，那可能没关系，因为耳塞可能会接收到来自墙壁或天花板的反射信号。但是如果你在外面，没有那些反射面，就会丢失更多的数据包。

在上一章中，我们看到同步通道的设计通过使用重传、预传输、突发数、刷新超时和跳频来增加鲁棒性。如果我们应用足够多的这些特性，我们就有很高的信心相信几乎每个数据包都会通过，并且可以使用 PLC 填充那些没有完整到达的小部分。然而，随着我们应用这些技术，延迟开始增加，功耗也随之增加。跨多个isochronous间隔传播重传会为每个额外的isochronous间隔增加额外的帧时间。在单个帧中进行更多重传会限制可以容纳的不同流的数量并提高功率——无论是对于发射机，还是对于接收机，都需要保持活动状态以寻找连续的传输时隙。

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

鉴于允许的大量可能的编解码器和稳健性配置，BAP 定义了针对两个主要用例的标准组合集 – 低延迟和高可靠性，可在 BAP 的表 5.2 和 6.4 中找到。它们涵盖 10 毫秒和 7.5 毫秒的帧间隔。

低延迟被解释为允许所有重传适合于 8kHz 到 32kHz 采样率的单个isochronous间隔内的设置。 448kHz 的较大数据包扩展到两个等时间隔，对于 44.1kHz 可达四个等时间隔。 高可靠性 QoS 配置优先考虑重传而不是延迟，允许重传跨六个或更多isochronous间隔进行广播，十个或更多单播。

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

• SDU 间隔（与帧持续时间相同，44.1kHz 除外）
• framed要求（除 44.1kHz 为framed外，均为unframed）
• Maximum_SDU_Size（与 Supported_Octets_per_Codec_Frame 相同）
• 针对低延迟和高可靠性选项的推荐重传编号 (RTN)
• Max_Transport_Latency 用于低延迟和高可靠性选项，以及
• Presentation Delay，需要 40ms 的值才能在支持的范围内。

使用这些表中的值可能并不总是产生预期的延迟。原因之一是 Presentation Delay 的值。 BAP 要求所有音频接收器在其支持的值范围内包含 40 毫秒的Presentation Delay，但不应将其视为默认值——它在表底部的注释中所说——必须是每个充当音频接收器的acceptor都支持。这是对互操作性的妥协，以确保一切都有时间解码音频数据、应用 PLC 和任何其他处理。大多数设备将能够做得更好。一些更高层的profile需要更严格的性能。 TMAP 和 HAP 都要求 Acceptor 支持 20ms 的 Presentation Delay 进行广播，但如果 Initiator 将其设置为 40ms，则会影响延迟。

回顾图 5.7，该示例中的Presentation Delay仅为 5 毫秒左右，导致总延迟低于 25 毫秒。许多助听器将能够支持这一点，但它是高度优化的。在单播中，Initiator 和 Acceptor 相互交谈，当 Initiator 知道它正在交付低延迟用例时，他们可以就较低的 Presentation Delay 值达成一致。然而，一个基本的广播源无法知道它周围的广播接收器的能力，因此必须根据用例和市场上的广播接收器的能力以及它的设计者的知识来做出决定expect 将访问它。

如果一对 Acceptor 可以相互通信，则可以单方面采取行动，方法是提前做出渲染决定，可能基于流的Context类型。但是，这超出了LE audio spec的范围。

回到表 5.5 中的低延迟列，当用于环境声音应用时，高于 32 kHz 的采样频率可能会产生回声效应。没有一个高可靠性设置真正适合增强环境声音，尤其是广播。

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

RTN – 重传编号，受益于一些进一步的解释。某些配置中的较大值表明重传次数较多，但不一定如此。 RTN 在核心 [Vol 4, Part E, Sect 7.8.97] 中定义为 CIS 数据 PDU 在被确认或刷新之前应该从 Central 重传到 Peripheral 或 Peripheral 到 Central 的次数。对于广播，它只是应该重传 PDU 的次数[第 4 卷，E 部分，第 7.8.103 节]。正如我们已经看到的，Host 不允许为 FT、PTO、NSE 或 BN 指定值，因为它不知道 Controller 可能还有哪些其他约束。因此，RTN 只是帮助指导 Controller 的调度算法的建议。

大多数情况下，音频数据不会传输 RTN 次。 RTN 最好解释为最大重传次数，而不是平均次数。如果一个 SDU 的 FT 大于 1，并且该 SDU 被传输了最大次数（RTN + 1）次，那么后面的 SDU 将只有 1 次传输机会，并且不可能重传。 RTN 提供了获得更多传输时隙以适应短脉冲干扰的机会，但将其设置得太高可能会惩罚后续的 SDU。传输机会的平均数量总是 NSE/BN。已经指出，BAP 表 5.3 和 6.4 中给出的值已经过很好的测试，通常应遵循。但是，如 BAP 表 6.5 所示，controller可以选择其他值。

• Option 1 的空中传输时间最短，针对与 Wi-Fi 和其他以 7.5 毫秒时间表运行的蓝牙设备共存进行了优化。使用更大的isochronous间隔来承载多个 10ms 帧，为 Wi-Fi 操作提供最大的间隙。如果广播源是手机或 PC，并且正在使用 Wi-Fi 获取音乐流以通过LE audio 发送，这非常重要。此选项使用最少的LE audio 传输的空中传输时间，但具有最高的延迟。
• Option 2 旨在提供最高的可靠性和最低的延迟，最大限度地增加每帧中的重传次数。它使用最多的空中传输时间，因此仅适用于没有其他 2.4GHz 无线电操作的广播设备。
• Option 3 旨在平衡可靠性和共存性。对于使用 Wi-Fi 获取音乐流但没有其他共存问题需要解决的Broadcasters来说，这将是一个不错的选择。

这些只是芯片调度程序可以选择的许多可能组合中的三种。随着行业对低功耗蓝牙音频的了解越来越多，随着时间的推移，其他产品可能会被添加到推荐列表中。

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

空中传输时间是一种有限的资源，提高音频质量和流的可靠性会占用它。LE audio 的设计要求之一是能够支持多个音频流，允许电视或电影院以多种语言传输音轨。查看图 5.8，很明显，任何 48kHz 采样配置都不可能，除非使用多个无线电来传输每个不同的立体声语言流。相比之下，低延迟 24kHz 或 32kHz 配置可以轻松应对两种不同的立体声流。如果产品设计人员想要利用LE audio 传输多个流的能力，他们需要考虑空中传输时间的影响。这给我们带来了音频质量。

5.7 音频质量

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

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

在 LC3 编解码器开发过程中，Bluetooth SIG 委托对其与其他编解码器的音频质量进行了独立研究。结果证实，在从 8kHz 到 48kHz 采样的整个频谱中，它提供了与其他编解码器相当或更好的主观性能。可在蓝牙 SIG 网站上收听 LC3 编码音频流的示例。

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

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

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

过去，音频行业曾两次决定降低音频质量。首先是CD的引入。第二个是 MP3 的使用，它启用了音频流。每次，在更易于使用与保持当前音频质量之间都存在平衡。在这两种情况下，消费者都表达了对易用性的主要偏好。

5.8 多声道LC3音频

在选项 (b) 和选项 © 中，initiator在编解码器配置过程之后接收到的通道分配和音频接收器位置信息与如果接收器是立体声设备将接收到的信息相同（参见图 5.10）。这意味着Initiator无法知道它是单声道设备还是立体声设备。因此，它为它提供立体声信息，或者作为选项 (b) 中的两个单独的 CIS，或者作为选项 © 中单个 CIS 上的多路复用流。在这种情况下，Acceptor 负责对结果流进行缩混。

BAP 要求所有设置多个LE audio 位置的设备能够支持至少相同数量的流，因此在选项 (a) 中，Acceptor 还需要能够支持选项 (b) 的两个 CIS 配置.如果它需要initiator执行缩混，它会在首选 PAC 记录（我们将在第 7 章中介绍）中指定单个通道分配和左加右音频位置，以表明它对单个单声道流的需求。

在选项 (b) 中，两个耳塞都将其频道分配设置为 2，因此它们将接收多路复用流。然后每个耳塞必须解码他们需要的流，丢弃另一个。这是一个效率较低的选项，但如果耳塞检测到用户已经转身，则允许耳塞交换流，因此在 3D 声音和虚拟现实耳机中也有应用，特别是在有额外空间音频内容可用的情况下。

上面显示的配置只是可能组合的一小部分，并不是每个 Initiator 和 Acceptor 都支持所有这些。 BAP 列出了 14 种不同的流配置组合（并非详尽无遗），规定了最常见的组合，并对其他组合应用有条件的和可选的要求。表 5.10 显示了 Initiator 和单个 Acceptor 之间的连接要求。 M 表示它们是强制性的，并且必须得到LE audio 兼容设备的支持。 C是条件支持，一般是根据设备是否支持双向流来判断的。 O 表示支持是可选的。这些的全部细节，包括条件要求是什么，可以在 BAP 的表 4.2 和 4.24 中找到。

许多其他组合是可能的，但LE audio 设备不能自动期望它们在initiator或acceptor上得到支持。发起方可以根据 PAC 记录和 Codec_Specific_Configurations 中的 Additional_ASE_Parameters 值确定对其他配置的支持。

5.9 其他编解码器

LC3 是一款非常出色的编解码器，可用于语音和音乐应用的各种采样率。每个LE audio 设备都必须支持 16kHz 和 24kHz 采样率（发起方只需要支持 16kHz，因为某些公共广播系统可能只有语音），但大多数实现可能支持更高的采样频率.

尽管如此，在一些特殊的应用程序中，其他编解码器的性能可能会更好。为了适应这一点，LE audio spec允许使用额外的编解码器或供应商特定的编解码器。

附加编解码器过去在 A2DP 中称为可选编解码器。这些是由外部spec机构或公司设计的编解码器，但蓝牙spec包括允许合格设备识别它们存在以及如何设置它们的配置信息。这允许多个制造商添加使用它们的功能。没有它，连接将默认返回到强制性蓝牙编解码器。通常，额外的编解码器可以从外部标准组织获得许可，因此任何人都可以将它们集成到他们的产品中。目前，没有为LE audio 定义额外的编解码器。

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