1044
在之前的文章中，曾经梳理过蓝牙技术计划路线，也就是在BLE传输基础上做得LE Audio Codec的演进。之前对于SIG官方给出的宣传文档中，如何在低数据率下保持高通话质量的技术点存疑，但一直未预留出时间详细解读。后续在与一位某欧洲蓝牙RFID公司BD，之前曾是Nordic出身的行业大前辈探讨，对方竟然对于蓝牙但双模的概念做了混淆，特别在聊到LE Audio的时候，经典蓝牙A2DP混为一谈，笔者对此深表痛心。此经历也更加提醒笔者，不论深耕领域多久，都要饱有敬畏之心，保持求真精神。于是刚好利用此空闲时间，梳理Low Complexity Communications Codec的部分细节。
在官方的介绍中，LE Audio将包括一个新的高质量，低功率音频编解码器，低复杂性通信编解码器LC3——The Low Complexity Communications Codec 。即使在低数据率下也能提供高质量传输，LC3将为开发人员带来巨大的灵活性，允许他们在关键产品属性(如音频质量和功耗)之间做出更好的设计权衡。
广泛的听力测试结果表明，LC3将提供改善音频质量的SBC编解码器包括与经典音频，即使在50%的低比特率。开发人员将能够利用节省的电量来开发产品，以提供更长的电池寿命，或者在当前电池寿命足够的情况下，通过使用更小的电池来达到产品更精巧的外观。（笔者注：这里广泛的听力测试结果，表明音质并不受影响，根据推测应该更偏向于人的主观听感，也就是在实际人耳听到传输音频感受的清晰度，并不是直接对比数据比如丢包率等具体参数而得到的结果）
甚至因为此类技术的推进，以及2017年自美国助听器市场相关法规的发布，一些传统音频公司已经在开始挑战诸如GN Audio等老牌音频领域的专业市场。以听力增强，结合蓝牙低功耗传输为买点，为一部分潜在需要听力增强辅助设备的人群提供帮助。举例，Bose已经推出的耳机产品，以及森海塞尔呗收购计划等等。
在之前的文章中，我们有讨论过听力补偿在助听，辅听产品方面的应用。
我们知道，目前的助听市场还是以GN Audio等集团下的专营品牌产品为主，但是此类产品使用蓝牙技术做通讯的比例不多。虽然，我们看到在此类应用苹果开发了MFi，谷歌开发ASHA，但是毕竟不通用，也并非主流，传统助听领域主要还是有线产品，或者通过NFMI线圈来设计。目前市面上的TWS耳机也有部分产品使用助听类的技术，比如，为了降低左右耳通讯延时而不选择蓝牙转发模式，而是NFMI技术，像是比较初代的TWS耳机产品，像是Sennheiser，Beoplay E8，以及Jabra过Teams认证的TWS产品等。（笔者注，例如在TWS Jabra商务款，就是用了额外的Dongle链接电脑设备，使用的方案为：NxH2281A1 NFMI TWS，其特点就是耳机内置较大线圈）
总体来讲，助听和辅听设备，都需要解决长期佩戴的功耗问题。所以即使有些产品使用蓝牙方案，但是给到用户的可选购空间是很少的。根据官方给出的解释，LC3 Codec可以保证低功耗的同时，保持音频的质量。同样，这里我们对于Audio Quality Rating的评分标准存疑，因为并未公布测试细节。（笔者注：从前文的推断，我们猜测或许依旧属于人耳佩戴耳机等设配后的主观感受，至于丢包率，可能是一直丢的，只是小细节人耳不够敏感，无法捕捉。）
以下内容包含LC3文档原文，增加了部分重点备注：
首先广泛化，The LC3 can be incorporated in any Bluetooth audio profile.LC3的Codec针对蓝牙音频格式并无限制。
保证了听感舒适的基础上，实际上，在音频接收端，是接受了一定的丢包数据隐藏Packet Loss Concealment (PLC)。
这里提到了关于LC3的一个很重要的概念，PLC，也解释了传输轻量级数据的同时，保证通话质量的根本，就是从一开始，就允许数据丢包现象的发生。这里对比传统意义上的A2DP，虽然在音乐传输的过程中也存在一定的丢包，但是核心是为了尽量不影响实际听到的音频细节。但是我们知道，本身通话的过程中，人耳希望听到的声音种类更单纯，也就是对方说话的内容，集中的声音频段更小，信号的特征类型也更加一致和明显，同时结合人类说话和发音的习惯，对于一些延长音调，或者习惯用语，部分丢包几乎不影响听感。
实际上，PLC的核心，就是基于之前的经验，提前预判，当部分用于解码的帧数据无法获取，或者干脆传输被打断时，直接隐藏这部分丢包情况，不进行“上报“。
The purpose of packet loss concealment is to conceal the effect of unavailable or corrupted frame data for decoding.
接受丢包数据隐藏需求，基于需要隐藏部分不可看的数据和解码过程中帧数据不能成功被获取，或者传输被打断。这个过程在代码中的具体实现，则是通过设置Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" （RFU）(irrespective of whether in uppercase or lowercase),数据接口单元，可能会先行保留数据，为后续做准备。除非另有规定，否则创建该结构的设备应将其值设为零。 任何接收或解释该结构的设备都应忽略该字段；特别是，它不能因为字段的值而拒绝代码架构的组建。总体来说，在代码上做出了一些提前设定，可以简单理解为忽略丢包，持续运行，部分保留数据值设置为零。
LC3支持以单元格式音频编解码，以支持在算法方面的低延迟，低复杂性补偿，以及很宽范围的可用比特率。编码器和解码器框架时间间隔分贝为：10ms和7.5ms，测试数据频率范围为：8 kHz, 16 kHz, 24 kHz, 32 kHz, and 48 kHz.
样本的输入信号44.1kHz，框架长度与48kHz一样，框架时间间隔实际会稍长，frame duration of 10.884 ms for the 10 ms frame interval and of 8.16 ms for the 7.5 ms frame interval
LC3的总编解码器算法延迟是帧持续时间与编码器侧MDCT (Modified Discrete Cosine Transform)超前持续时间之和如下：
基于额外设置的比特率，LC3的编码算法在每通道压缩单向脉冲编码调制框架，并提供原码解码位，（每个channel定量有效负载），不需要额外的传输通道用于有效负载上限的错误保护。
The size of the payload for a single channel ranges from 20 bytes to 400 bytes for each frame and corresponds to an overall compressed bitrate range of 16,000 bps to 320,000 bps for 10 ms frames and to an overall compressed bitrate range of 21,334 bps to 426,667 bps for 7.5 ms frames.每个frame框架单通道的有效负载范围为（所有可压缩的比特率范围大概在见上）
For 10.884 ms duration frames, which are used for the 44.1 kHz sampling frequency, the corresponding bitrate range is 14,700 bps to 294,000 bps for the 10 ms frame size and 19,600 bps to 392,000 bps for the 7.5 ms frame size. The LC3 can be operated at a constant bitrate or at an externally controlled variable bitrate.
To decode the received payload, the LC3 decoder relies on an externally determined Bad Frame Indication (BFI) flag and a payload size parameter for each channel. 为了解码收到的负载包，解码器需要额外定制的BFI（标记），以及给到每个通道的负载总量数据。
BFI flag是用于标记丢包，或者在收到的负载包在解码的过程中发现bit error。这个参数同样用于定义内部的额定负载两，是的外部应用在解码过程中定义损坏负载。一旦LC3解码器解读到包数据又损坏，就会直接跳过，并且启动PLC算法用于为被解码成功的PCM输出信号。因此，额定负载包的尺寸参数，可以使得LC3解码器正确地解析每一个包。额定负载包不包含任何时间相关地参数，比如time stamps或者数列值。
这种细节，使用公式和整数伪码，使得整个编码的效率，可以基于任意的架构上，得到增补。比如，针对功率优先的听力辅助设备，蓄电池因为耗电限制的原因，在效率方面，控制在24-bit的浮点运算级别。如下的框架描述了LC3解码器，在详细参数方面，在正式开始数据传输过程中，框架对应框架的解码方式。
Encoder session configuration (identical for all encoded frames in a session)
解码器配置
Table 2.2 关于使得LC3解码在可以开始解码输入信号之前，的frame参数
Table 2.2: Encoder frame level inputs required for every frame to compress
Table 2.3 LC3解码器解码后的输出frame描述
下图描述了LC3如何操作的简略流程：
Figure 2.1在一个案例中，链路层与LC3编/解码器之间与比特率相关的参数
The profile in Device A defines a byte_count in bytes that the LC3 encoder will use to generate the compressed payloadTX for an audio frame. (The resulting size of the payloadTX will be exactly byte_count.) A设备中，profile定义以byte count，以LC3解码器，从音频框架中，生成一个压缩的payloadTX，也是以byte count为单位存储。
只要byte_count的尺寸比链路层最大frame size框架限制尺寸要小，或者等于，那么A设备就可以把payload传输到B设备上。
当B设备接收到解码的payload之后，一个BFI（Bad Frame Indicator）flag被生成，传输到解码器端。
Figure 2.2:在单声道，用单一固定比特率LC3传输数据的流程示意
在比特率固定，单声道情况下，使用LC3解码时，所有的frames比特率相同，同时每个audio sample的分辨率bits相同。
实际的kbps比特率与byte_count（单位为bytes）有关，而tuple的参数{FS, Nms},FS代表音频样品频率，Nms带表frame长度（单位为微秒）。编码器和解码器需要被配置和initialized使用相同的通用参数数据。除了audio sample的bits参数，其他参数需要在编解码器之间共同配置。每个框架，LC3的frame编码器接受的输入PCM信号，都会被压缩成一个缓冲尺寸，（具体计算方法为NF乘以音频样品的bits再除以8）以bytes为单位表示。LC3的frame编码器，产生一个缓冲payloadTX，以byte_count为单位，在这个场景下，byte_count的单位是以session byte_count的参数决定的。
The Transmitter transmits the payloadTX over the air interface and the Receiver receives the transmitted information as payloadRX of size byte_count. 通过空中传输payloadTX，尺寸单位为byte_count。如果接收端在payloadTX正常传输，则BFI flag值为0，发现错误，BFI flag的值非0.当BFI为0，则不会使用接收到的payloadRX进行编解码。Implementation或者profile会决定bad frame将被如何处理。每个正确的frame，LC3解码器会输出一个PCM信号，都会被压缩成一个缓冲尺寸，（具体计算方法为NF乘以音频样品的bits再除以8）以bytes为单位表示。
Figure 2.3: LC3的全能力操作，使用外部速率控制多个音频通道
上图也可以简单总结为多声道，非固定
外部速率控制(基于帧和音频通道)可以通过使用LC3的配置文件指定，例如支持内容增强和/或编解码器重新配置，而不需要拆除流。 编码器和解码器可能使用不同的位为每个音频样本分辨率(bits_per_audio_sample_enc, bits_per_audio_sample_dec)会话。 音频通道的数量由NC指示，并且在整个会话中是固定的。 对于多声道操作，每个音频样本的所有声道期望具有相同的位数; 因此，不是所有的配置参数都是独立的。
文档中同时也提供了LC3解码器在开始逐帧解码之前需要配置的会话参数的描述，这里就不作赘述了。
总结上述，配合PLC概念性的传输方式，可以初步在助听，特别是单声道助听领域，让更见便宜和便携的蓝牙助听，以及辅听设备成为量产可能。结合之前文章中提到的一些Broadcast应用场景，我们可以期待此类助听，辅听设备，将不仅仅可以将身边的声音放大，同时也可以接受机场，火车站，甚至电视的广播信号，更加清晰的或许关于出行，天气，新闻等通知的信息。
