总体来看，通讯发展经历了几个阶段-消息(电报)-语音通话-视频通话-AR/VR，当然声音在其中是少不了的，即使在视频和AR/VR阶段，都需要有声音的交流，总不能视频上光白活没声音吧。本文就分享一下在实时通讯领域音频编解码的一些经历和经验。
音频编解码其实有很多种，在不同领域有不同的应用，要理解这个首先要从人说话和人耳朵听到声音的频谱范围说起，人说话的声音频谱能量范围大部分分布在300~3400HZ，而人耳能听到声音的频谱范围一般为20~20000HZ，所以人耳是可以听到除人说话外的自然界的很多其他声音的，像乐器，自然界，尖鸣声等等。当然每个人都会不太一样，B站上有个可以测试自己听觉范围的，链接在下面，大家可以去试试(当然高频的时候如何有任何不适，本人概不负责)。https://www.bilibili.com/video/BV1Xs411s7qo?from=search&seid=12278321081543626393
同时科学界奈奎斯特定理表明，通过2倍于最高频率进行采样的，就可以完整的还原模拟信号。了解了这两个原理后，下面对音频编解码的应用就可以比较好的理解了。
先看一下音频编码和解码的整体流程
人说话的声音经过数字采样后，即为PCM原始采样数据，从图中可以得知，不过什么编解码类型，都是将PCM编码压缩方便传输，然后再解码恢复成PCM的过程。
首先看在早期的固定电话时期，固话时期的编解码主要有G.711a/u；G.729；G.722；G.723；G.726等等；这些编解码基本都是使用8KHZ的采样的，由于当时的通讯只是主要是人与人之间说话，8K采样率足以覆盖人说话声音的最主要部分能量范围了。最初的G.711a/u属于无损编码，但是由于要64Kbps的速率(但是ADSL电话线的速率也就是64K带宽)。
不知道还有多少朋友知道ADSL上网，最初就是用这64K的电话线传输，但是G.711把带宽占光了，还怎么传输数据呢，因此后续逐渐被压缩率更高但是效果也不逊色的G.729，G.726等编解码取代使用。其中G.722属于比较出名的一个系列，G.722.1是polycom研发的编解码，而G.722.2就是AMR-WB+，下面提到的AMR-WB的超宽带版本。
接下来到了移动通信(2G/3G)时代，由于通信的内容仍然是人与人之前的说话，所以编解码仍然是采用语音编解码，移动侧主要是使用的AMR(Adaptive
Multi Rate-Narrow Band Speech Codec)，AMR-WB(分别是窄带AMR和宽带AMR)。窄带AMR虽然仍然使用8K采样，但是从其全称可以看出，编解码本身是多速率(8种速率模式)，并且是可以切换的，这个特性的主要原因我认为是适应无线信道和传输通道的情况来自适应。举个例子，可以想象一下，一个基站，如果有10部手机通话和100部通话，每部手机被分配的信道带宽肯定是不一样的，速率变换则可以根据信道情况进行灵活的速率切换，从而保障更多人的通话。
再往后就是Volte(4G)，也就是大家当前在用的，采用了AMR-WB(Adaptive
Multi-RateWideband Speech Codec)；此编解码采用是16K采样，比原来高了一倍；产生的效果就是时域上每秒多采样8K个数据，频域上覆盖的高频范围更广，声音细节更丰富。不过对于消费者体验来说好像未得到大的提升。
但是到了4G时代，随着带宽越来越高，业务发展越来越丰富，为了提升语音清晰度和通话体验，几个大厂推出了EVS高清编解码，并作为进入3GPP的唯一标准，EVS兼容了AMR-NB和AMR-WB，同时支持SWB(超宽带)和FWB(全宽带)采样(最高到48KHZ)，已经覆盖人耳听到声音的全部频谱范围了。大家手机上可以看到一个“HD”的标签，这个其实就是E2了。随着EVS的推出以及新业务的推广(像最近的视频彩铃)，大家应该可以感受到更丰富的声音体验了。
当然到了3G/4G时代，随着互联网的发展，基于互联网的VOIP技术也蓬勃发展起来，但是基于互联网的VOIP比运营商语音通话面临着更加严峻的复杂网络情况，毕竟不是专网，因此面临的延时带宽问题更加严峻。VOIP的音频编解码也存在类似的发展阶段，首先是语音编解码，像iLBC和iSLK，这两种编解码都是GIPS公司开发的编解码技术，被Google收购后，两种编解码技术就用应用在WebRTC技术中并且开源了，ILBC编解码的特点是减少每个音频编码帧之间的冗余性，每帧独立可解，因此具备了很不错的抗丢包特性。ISAK我了解的不多，除了继承ILBC能力之外，好像是增加了带宽预测功能。红极一时的Skype使用的编解码则是silk，silk编解码对于语音有特别好的编码效果，据说可以使得通话双方听起来像双方在同一个房间里一样(silk源码原来在skype开发者网站开放的，不过网站现在无法访问了，可以到github上找下声网技术VP高大神共享上传的源码https://github.com/gaozehua/SILKCodec)
大名鼎鼎的WebRTC为了提升语音体验，默认使用的编解码就是Opus(silk编解码和celt编解码的组合)；此编解码器内一个Music detector去判断当前帧是语音还是音乐，语音选择silk，音乐选择celt(这款编解码我确实不太熟悉，不过据说高频领域比AAC弱一些)；同时opus支持PLC(丢包补偿)，具备较好的网络抗丢包特性。其实大家可以看到，WebRTC在google一直是走开源策略，如果不开源，google是不会使用的，像H.264因为不开源，google就另行开发了VP8，VP9，这个在后续的视频编解码里再探讨。
其实音频也不只在通讯领域使用，像AAC(Advanced AudioCoding（高级音频编码）)，是一种由MPEG-4标准定义的有损音频压缩格式，由Fraunhofer发展，Dolby, Sony和AT&T是主要的贡献者。在使用MP4作为各种内容的容器格式的新多媒体MPEG-4标准中，它是MPEG Layer III / MP3的天然后继者。AAC编解码跟Mpeg4的视频编解码协议类似，也分为多Profile，LC-AAC(低复杂性)和HE-AAC(高效性)，个人理解就是消耗CPU少和压缩率更高。
当然说道RTC技术，肯定要提到声网Agora，Agora在19年RTC大会上也开源了自研的编解码协议SOLO。SOLO应该是以Silk为基础，融合带宽扩展(BWE)和多描述编码(MDC)技术，打造出的一款不稳定网络下抗包出众的编解码，至于具体实现我就要去GitHub上学习了。
最近验证使用Agora的RTSA-Lite的SDK库，按照API接口文件描述，支持这四种编解码。可以看出其选择还是很有针对性的，opus可以无缝的和WebRTC对接；G722可以适应与移动端通讯；而两个AAC系列可以利用在音乐音质要求比较高的领域。(不知道为什么没有SOLO？)
最后，随着5G时代的到来，随着内容业务百花齐放，除了通话/音乐外，相信适用于新场景的音频编解码技术也会得到快速发展。像VR技术，就需要3D沉浸式的音频技术，像大家都知道的杜比全景声技术，像object based
audio和ambisonics技术；随着网络带宽不再是问题，音频编解码应该不会再区分音频和音频了，融合是趋势；所谓体验无止境，从而音频编解码技术也无止境。
其实作为业务开发者，我觉得应该了解的是编解码的特点，结合你所在领域的业务特点，以及业务所处网络，带宽，丢包等等因素，已经编解码所在硬件的处理能力(内存/CPU/协处理器)，从而可以做出正确的选择，初期我们是把这项技术应用在业务领域为客户提供好的体验(毕竟这个领域的大大神们研究了这么多久，我们没必要从信号采样再研究起)；对于编解码内核的频域转换/滤波等原理性技术可以随着业务的发展，当然结合自己的能力，再逐步加深学习。
本文为个人原创，首发于声网开发者社区https://rtcdeveloper.com/t/topic/20155