Skip to content

A2DP Codec

从 1998 年蓝牙技术的诞生开始，蓝牙一步步的走进我们的生活，蓝牙耳机、蓝牙音箱以及各种物联网的低功耗蓝牙设备等等，无处不在。蓝牙用户体量不断增大，蓝牙技术也不断的进步。其中蓝牙耳机也在蓝牙技术进步的基础上不断的完善。

随着蓝牙 A2DP（Advanced Audio Distribution Profile 蓝牙立体声音频传输规范）的发布和普及，蓝牙耳机的音质也有了进一步的提升，受众也越来越广。而各大手机厂商取消 3.5mm 耳机接口，对于蓝牙耳机的音质也有了跟进一步的追求。不过苹果发布 AirPods，则是完全引爆了 TWS （True Wireless Stereo）市场，虽然从另外一个角度打开了蓝牙市场。

既然聊到蓝牙耳机的音质，本文就来聊聊各种蓝牙耳机宣传中最常出现蓝牙音频解码技术。当然音质这个东西不是仅仅受某一个点的影响，是一整套系统的影响，本文仅仅只是讨论比较容易量化的一部分内容。

蓝牙的编码简介

SBC

简介 SBC 全称是 Subband Coding（子带编码），是一种专门为蓝牙音视频应用设计的音频编码系统，可以使用中等比特率获得高质量的音频，并且具有较低的计算复杂度，因此 SBC 也可以在比较低的性能的硬件上良好的运行。

SBC 是 A2DP 协议中要求必须实现的蓝牙解码方式，是蓝牙协议为了保证 A2DP 的兼容性要求的一个编码器。关于 A2DP 中 SBC 的要求可以参看下表，具体文档可以参考[1]。
蓝牙协议解码要求

A2DP 中规定 SBC 编码支持最大比特率是单声道 320kbps，立体声 345kbps。但按其推荐，实际上使用最多的是 44.1KHz@328kbps 的立体声传输。

原理： SBC 的原理是使用带通滤波器将输入的音频数据分成 4 或 8 个子带，然后为每个子带指定一个缩放因子及采样深度，对这个子带的数据进行自适应 PCM 编码（Adaptive Pluse Code Modulation），最后将编码后的数据打包成二进制的比特流，按照 A2DP 的要求输出。 可以参考如下流程图，图源[1]。
蓝牙 SBC 解码流程

  • Polyphase analysis
    其目的是将输入的 PCM 音频序列变换到频域，使用的方法是已经定义好的多相滤波器组（带通滤波器）。子带的数量可以是 4 个或者 8 个，他们分别对应不同的多相滤波器组。经过处理后输出的就是多个子带序列（Subband samples）了。

  • Derive allocation
    将子带序列按照不同的缩放因子（Scale Samples）转换成 Levels。每个子带的幅值的范围是不同的，取每一个子带幅值的最大值作为这个子带的 Scale Factors。比如子带的幅值分布在（0，128）这个区间，那么自定子带的 Scale Factors 为 128，然后将其转换成 Levels。

  • APCM
    将子带序列（Subband samples）和每个子带产生的 Levels 进行编码的过程，这个就是自适应 PCM 编码。经过自适应 PCM 编码处理后输出的就是量化后的子带数据（Quantized Subband samples）。

  • Bitstream packing
    将量化后的子带序列进行比特流打包，最终输出成比特流，然后作为 A2DP 的数据发送出去。

这样做的好处是：舍弃或减小人耳听觉不敏感的频率部分，在敏感频率处采用较细的量化，在低比特率条件下获得更好的听觉效果。

AAC

简介 AAC全称Advanced Audio Coding，高级音频编码，1997年诞生，为一种基于 MPEG-2 的有损数字音频压缩的专利音频编码标准。2000 年 MPEG-4 在 MPEG-2 基础上增加了一些特性，为了区分一般分别称为 MPEG-2 AAC 和 MPEG-4 AAC。也是属于 A2DP 中定义的一种编解码器，不过属于可选的实现，因此并不是所有的蓝牙设备都包含有 AAC 的编解码实现。

不过目前的蓝牙设备基本都支持 AAC 了，例如目前的 iPhone（iOS 系统） 中就包含有 SBC 和 AAC 这两种编解码器，而 AOSP（Android 由谷歌释放的标准开源 Android 系统） 默认系统中有 AAC 编解码的支持，不过 Android 系统针对 AAC 也有一个白名单机制，这个可能部分手机厂商去修改白名单机制，另外也有可能部分手机厂商直接移除了 AAC 编解码支持，因为 Android 8.0 之后已经包含有 LDAC 的编解码了。

AAC 编码支持最大比特率是立体声 576kbps，范围是 8~576kbps，采样率范围为 8k ~ 96k 。但按其推荐，实际上使用最多的是 44.1/48KHz@256~320 kbps 的立体声传输。

原理： AAC 目前的标准中包含有 MPEG-2 AAC 和 MPEG-4 AAC，而他们又分别包含有不同的层次的应用。A2DP 中支持以下四种层次的应用，分别为 MPEG-2 AAC LC、MPEG-4 AAC LC、MPEG-4 LTP 和 MPEG-4 AAC scalcable，如下图所示。 蓝牙 AAC 支持

MPEG-2 AAC 整体的原理流程图如下图所示，不过我们可以看到蓝牙使用的场景一般比较受限，因此都是必须实现的也只是 LC 层次的应用。 蓝牙 AAC 处理流程图

MPEG-2 AAC 的 LC 描述中，要求不使用预测（prediction）和增益控制工具（AAC gain control），并且TNS 也是受到限制的。同时在 LC 的 bit 流中的也不应包含任何单声道或立体声混音元素。

关于 AAC 的更多原理介绍可以参看另外一篇介绍 AAC 原理的文章，也可以直接查看更为详细的 MPEG-2（ISO/IEC 13818-7） 和 MPEG-4（ISO/IEC 14496-3） 的官方文档。

aptX\aptX LL\aptX HD\aptX Adaptive

简介： 蓝牙的音频编解码器，由高通开发，不是 A2DP 中定义的编解码器，属于第三方厂商自己定义的编解码器，由于高通芯片在手机市场的强势地位，目前已经大量普及开来。

目前市场上的发射端（Source）设备基本上都是使用高通芯片方案的手机厂商，当然也有部分 HiFi 音乐厂商虽然没有使用高通芯片方案，也提供了 aptX 发射功能。接收端（Sink）设备也大多是使用高通芯片的蓝牙耳机。这里还有多说一句就是目前蓝牙的第三方编解码都是采用的发射端（Source）免费使用，而接收端（Sink）需要收费的方式。

aptX 最开始是由 Audio Processing Technology 公司发展并命名为 apt-X，最初用于专业音频与广播领域。apt 应该就是 Audio Processing Technology 公司名字的首字母的缩写，X 我猜测是扩展（eXtended ）的意思，不过年代久远也只有猜测了。后来英国蓝牙芯片厂商 CSR 公司收购了 Audio Processing Technology ，并且在他们的蓝牙芯片方案中推广使用 aptX 技术，这个时期 aptX 由于他的低延时，容错性好，高音质等优点开始被广泛使用。2015 年，高通公司收购了 CSR 公司，将 aptX 技术也收入囊中，并且将 aptX 内置到了高通的手机方案中，后续高通公司在 CSR 蓝牙芯片基础上推出的一系列蓝牙芯片也都包含有 aptX。

aptX 编码支持最大比特率是立体声 576kbps，范围是 56~576kbps，采样率范围为 8k ~ 96k 。但按其推荐，实际上使用最多的是 44.1/48KHz@352~384 kbps 的立体声传输。

原理： 不同于 SBC/AAC 这些基于心理声学模型的编码方式，aptX 采用的是基于 SubBand-ADPCM（子带自适应差分脉码调制）技术的数字音频压缩算法。关于 SubBand-ADPCM 的资料可以参考《有损压缩技术简介》这篇文章。 蓝牙 aptX 支持

资料来源：http://www.aptx.com/which-aptx

从上表可以看出 aptX 的四个版本各有所长。 aptX 是最基础的版本，可以作为 atpX 系列的一个基准。

aptX Low Latency 简称 aptX LL，特点在于低延迟。在做蓝牙开发的时候，对 aptX LL 除编解码以外的代码做过一些基本的分析，看到所有涉及到 aptX LL 的地方都会减少中间 buffer（缓冲区）的大小，这样就能减少各个环节的延迟以达到低延迟的目的。研究表明人耳可以感觉到的延迟极限是70ms，而达到40ms则意味着我们不会感觉到延迟。不过很可惜目前支持 aptX LL 的 Source（发射）设备很少。这中间也涉及到一个最大的发射设备，智能手机。以 Android 为例，中间需要经过 Android 系统的处理，然后再经过蓝牙发射出去，每个环节的处理都会导致延迟的增加，因此 aptX LL 本身宣传的延迟在手机上其实也比较难实现。

aptX HD 主打高清音频，这主要得益于传输速率的大幅增加，编码的时候可以选择损失更小的处理参数和处理方式，最终达到更高的信噪比和更小的失真。通过分析 FFMPEG 中 aptX 源看到，aptX HD 和 aptX 的区别主要是：1、块大小（block_size），aptX 为 4，aptX HD 为 6；2、不同子带 ADPCM 处理的参数表；

aptX Adaptive，翻译过来就是 aptX 自适应，这个编码就跟它名字一样可以按需自动调节传输比特率。目前没有找到资料来确认是按照信号质量来调节传输比特率还是按照音频内容来调节传输比特率。这里也说明下，LDAC 的自适应模式是按照信号质量来调节传输比特率的。aptX Adaptive向下兼容aptX和aptX HD。

LDAC

简介： 蓝牙的音频编解码器，由 Sony 开发的音频编解码，最高支持 96k 采样率的输出，最高能够达到 990kbps 的传输比特率。（在 Android 8.0 之后 Sony 将 LDAC 作为 Android 开源计划的一部分释放了出来，因此所有在 Android 8.0 这个版本之后系统已经预置了该编码器，如果你的系统是 Android 8.0 之后但是没有包含 LDAC 编码的话，那么就应该是厂商对这部分做了限制）

原理： LDAC 是一种有损编解码器，采用基于改进的离散余弦变换（MDCT）的混合编码方案来提供更有效的数据压缩。

关于 LDAC 的特性，我们可以在 LDAC 的官网找到如下信息： LDAC 特性 1、无与伦比的音质 LDAC 支持以 990kbps 的最大比特率通过蓝牙传输音频内容，包括高分辨率（Hi-Res）音频。LDAC 是 “Hi-Res Audio Wireless” 的认证编解码器(1） （1）LDAC在990 kbps的传输速率下满足“Hi-Res Audio Wireless”徽标的要求

2、高可靠性的 “尽力而为”模式根据网络状况自动控制比特率，即使在恶劣环境下也能保证稳定的连接。

3、兼容多种设备 LDAC 与多种设备兼容，因为 LDAC 是一种软件编解码器。

4、LDAC 为 Android 操作系统实现 LDAC 源代码被贡献给 Android 开源项目，允许 SRC（智能手机）制造商免费安装 LDAC 软件（1）LDAC 被实现为 Android 操作系统的第一连接优先级。 （1）实施 LDAC 软件（SNK）需要索尼的许可证。 蓝牙 LDAC 速度

上图是 LDAC 官网提供 SBC 和 LDAC 的传输速率对比图：不过这个对比其实并没有多大的意义，因为 SBC 也可以通过提高传输速率来提高音频质量。而对于 LDAC 来说为了兼容不同的环境的影响，默认都是使用的是自适应传输速率，也就是会根据具体的蓝牙信号环境来调整传输速率。

上图是 LDAC 官网提供 SBC 和 LDAC 编解码后的音频质量对比图： 蓝牙 LDAC 质量

从上图可以看出 SBC 遇到 96k@24bit 的音频，需要先下采样到 44.1k@16bit，然后进行 SBC 编码，再通过 328kbps 的速率传输到接收端，最终解码成 44.1k@16bit 的音频。这个过程由于 SBC 不支持 96k@24bit 的音频，因此在 SBC 编码之前需要多进行一次下采样。

同时也可以看出 LDAC 可以实现 96k@24bit 的音频，经过 LDAC 编码，然后通过 990kbps 的速率传输到接收端，再通过 LDAC 解码恢复到 96k@24bit。对比 SBC 来说，LDAC 少了一个下采样到 44.1k@16bit 的过程，同样最终也可以恢复到 96k@24bit。

蓝牙 LDAC 路径 虽说 LDAC 官方的图描述的很美好，但实际上 LDAC 的最大使用群体 Android 手机用户却没有体验到这个过程，因为 Android 的音频系统很多还只支持 44.1k\48k 音频的输入，导致通过 Android 手机播放 96k@24bit 的音频中间可能会多一个 96k 到 44.1k 在转成 96k 输出的过程。如上图（a）。

而由于 Android 手机蓝牙目前只支持固定的采样率输出，因此你播放 44.1k 音频的时候，会重采样到 96k，然后经过 LDAC 编码输出。如上图（b）。

不过也有一些设备实现了 LDAC 官方图的直通输出方式，例如索尼的 NW35 以及海贝的 R3PRO 这种非智能的音频播放器。

LDAC 的标准实现中包含有自适应传输速率，连接优先，连接音质均衡，音质优先这四种传输速率。而自适应传输速率这种方式应该说是 LDAC 一个非常核心优势，不同的蓝牙连接环境下，通过调整传输速率达到调整音质的目的。

现在的无线设备越来越多，蓝牙在不同情况下信号质量也受到越来越大的干扰。LDAC 的自适应传输则可以实现：蓝牙环境好的时候 LDAC 会自动切换到 990kbps 去传输高音质的音频内容，而蓝牙环境差的时候为了保证蓝牙传输的稳定性传输速率会自动回落到 330kbps ，这个时候虽然传输的音频质量变低了但是蓝牙音频的稳定性得到了保证。

LHDC

简介： LHDC 全称 Low-Latency Hi-Definition Audio Codec，是一种低延迟高音质蓝牙编解码器，由台湾厂商 SAVITECH 盛微先進科技开发。该技术允许最高以 900kbps 的速度传输 96k@24bit 的高音质音频。

LHDC 也是继 Sony 的 LDAC 之后，第二个达到日本音响协会认证的 Hi-Res Audio Wireless 标准的蓝牙高音质编解码器。当然 LHDC 也是目前 HWA 标准认证的编码器。

最近日本音响协会更新新版 Hi-Res Wireless 规范，对高音质的真无线蓝牙耳机提出以下要求： 1、真无线蓝牙耳机，必须符合左右声道输出平衡； 2、采用 Sony 提出的 LDAC 蓝牙编码技术，或是台湾盛微先進科技 (Savitech) 提出 LHDC 蓝牙编码技术；

相较于 LDAC 会先把原始音讯进行升/降频到 96kHz@24bit 的模式， LHDC 则可依照原始取样率输出，减少 SRC 过程的延迟。 以上这部分内容摘自维基百科，但是这句话实际上是错误的， LDAC 并不是必须要将原始音频升/降频到 96kHz@24bit ，而是因为 Android 里面的 LDAC 实现中只支持固定采样率输出导致的，但是其他的一些非 Android 设备是可以正常实现原始采样率输出。例如索尼的 NW35 以及海贝的 R3PRO 这种非智能的音频播放器。

以上文档里面频繁的出现了一个 Hi-Res Audio Wireless 的认证，这个和 Hi-Res Audio 的认证一样的也是由日本音响协会提出的一套认证标准，也就是小金标。

原理： 从 LHDC 的相关网站，我们找到了关于 LHDC 的以下特性： 1、LHDC 编解码器传输的数据量是其他技术的（这里根据上下文应该是指 SBC） 3 倍以上； 2、LHDC 编解码器可以提供的出色音质； 3、传输数据的增加使用户能够体验更多细节和更好的声场， 并沉浸在音乐的情感中；

蓝牙 LHDC 路径

从目前 LHDC 的相关信息来看，我们只能知道 LHDC 和 LDAC 一样也是通过提高传输速度来进一步提高传输音频的音质，而对于音频本身的压缩算法并没有什么有效的信息，不过从其他不同类型的解码器信息来看，LHDC 应该也是基于心理声学来进行压缩的。

Codec Sampling Rate Word Bit Rate THD+N(Digital) SNR@1kHz Frequency respnose
SBC 16k-48k 16bit 127-345kbps >-80dB -
AAC 8k-48k 16bit 128-392kbps >-80dB -
aptX 16k-48k 16bit 384kbps@48k -85dB 93dB 20Hz-22.7kHz
aptX LL 16k-48k 16bit 352kbps -85dB 93dB 20Hz-22.7kHz
aptX HD 16k-48k 24bit 570kbps -90dB 129dB 20Hz-22.7kHz
aptX Adaptive 16k-48k 24bit 276-420kbps -100dB@420kbps -90db@276kbps 130dB@276kbps 135dB@420kbps 20Hz-22.7kHz
LDAC 16k-96k 24bit 330-990kbps -125dB -
LHDC 16k-96k 24bit 256-900kbps -141dB -

参考资料

https://www.bluetooth.com/specifications/specs/advanced-audi%e2%80%8b%e2%80%8bo-distribution-profile-1-3-2
http://www.aptx.com/which-aptx
https://zh.wikipedia.org/wiki/AptX
https://en.wikipedia.org/wiki/Advanced_Audio_Coding
http://www.caianet.org.cn/custom/index/24
https://zhuanlan.zhihu.com/p/298347871
https://zhuanlan.zhihu.com/p/56880153
https://www.cnblogs.com/huahuahu/p/lan-ya-xie-yi-zhong-deSBC-bian-ma.html
https://www.sony.net/Products/LDAC/
https://zh.wikipedia.org/wiki/LDAC
https://zh.wikipedia.org/wiki/LHDC
https://www.hwa-lhdc.org/how-it-works
https://habr.com/en/post/456182/

ADPCM
https://blog.csdn.net/houxiaoni01/article/details/104702570