本篇是「详解低延时高音质系列」的第三篇技术分享。咱们这次要将视角放大，从整个音频引擎链路的角度，来讲讲在时变的网络下，针对不同的利用场景，如何衡量音质和互动的实时性。
当咱们在探讨实时互动场景下的低延时、高音质的时候，咱们其实要面对的是从端到端整个音频引擎链路上的音质问题。咱们在第一篇文章中，简略的描述过一条音频传输的过程，如果在该根底上再进一步细化，音频引擎的整个链路蕴含以下各步骤：
1.采集设施 对声学信号进行 采样，造成计算机可操作的离散音频信号；
2. 因为音频信号的短时相关性，将音频信号进行 分帧解决 ，通过 3A 解决方案 解决声学、环境乐音、回声、自动增益等问题；
3.编码器 对音频信号进行实时压缩，造成音频码流；
4. 依据 IP+UDP+RTP+Audio Payload 的格局 组包 后发送端将音频数据包发向网络，重组 通过网络达到接收端的数据包；
5. 通过 抗抖缓存 和解码器重建间断的音频流 ， 播放设施 将间断的音频流播放进去。
在以上不同的音频解决环节中，都会不可避免地对音频信号产生一些伤害。咱们将上述因采集、播放而对音频信号引入的伤害称为「设施伤害」，在环节 2 引入的伤害称为「信号处理伤害」，在编码与解码过程中引入的称为「编码伤害」，环节 4 中的称为「网络伤害」。
如果要为用户提供全频带的高质量音频互动体验，就须要在上述的音频引擎链路反对全频带的解决，并在一些约束条件下（比方来自设施、网络带宽、声学环境等），将各个环节引入的伤害尽可能升高到最小。
当音频数据进入网络，它会遇到……
如果将网络视作信息的公路，那么音频数据包就像是一辆辆跑在公路上的车。这辆车从北京开到上海，路径的高速公路就是骨干网络，起伏山路就是弱网环境。假如每分钟都有一辆车从北京登程上路，那么他们会遇到三个实时传输中的常见问题：丢包、延时、抖动。
丢包
“丢包”指的是有的车无奈在无效工夫内无奈达到起点，甚至可能永远也到不了起点。有的车可能永远堵在北京的三环上了，有的车可能中途出了车祸。如果咱们的一百辆车里有五辆车因为各种起因没能按时达到上海，咱们这次车队传输的“丢包率”就是 5%。是的，互联网传输也一样，它并不是百分百牢靠的，总有数据无奈按时传输到目的地。
延时
“延时”指的是每辆车从北京鸟巢开到上海的均匀工夫。显然，车队走高速公路必定要比走各种小公路快很多，而且从鸟巢登程沿着怎么的路线开上高速公路也有很大影响，万一堵在了三环可就要多花好几个小时了。所以这个值和车队抉择的行驶路线无关。互联网传输也是一样的情理，须要传输数据的两点之间常常是有很多可选门路的，而这些门路的延时往往相差很大。
抖动
“抖动”指的是车子达到的程序、距离和登程时的差别。尽管咱们的一百辆车在北京是等距离的一分钟一辆登程的，然而它们达到上海时却并不是按程序一分钟一辆达到的，甚至可能有晚登程的车比早登程的车先到的状况。互联网传输也一样，如果简略地依照收到的音视频数据程序间接播放进去，就会呈现失真的景象。
总结来讲：
1. 在网络上进行实时的音频交互，编码后的音频码流依据实时传输协定组装成数据包。其中数据包从发送端依照各自的路线通过网络返回接收端。
2. 寰球范畴内，不同区域或者不同时间段，用户网络连接的服务质量有时十分差，且不牢靠。
基于上述起因，数据包往往不是按精确的程序达到接收端，而是在谬误的工夫以谬误的程序达到接收端，或数据包失落等，这就会呈现实时传输畛域通常提到的问题：网络抖动（jitter），丢包（packet loss），延时（latency）。
丢包、延时、抖动，是基于互联网进行实时传输不可避免的三个问题，不论是在局域网、繁多国家地区内传输，还是是跨国、跨地区传输，都会遇到。
这些网络问题，在不同区域的散布不同，以声网 Agora 监控的网络实况来看，在网络绝对较好的中国地区，99% 的音频互动须要解决丢包、抖动和网络延时等。这些音频会话中，20% 因为网络问题会有超过 3% 的丢包，10% 的会话有超过 8% 的丢包。而在印度的体现差别较大，80% 的音频互动中，大概有 40% 的会话失落。在印度地区优化 2G/3G 网络下的服务质量，仍是提供音频服务的重点。
抖动、提早、带宽的限度也是很多的，这些网络问题导致音频品质急剧下降，更甚者，影响音频信号的可懂度，即不能满足替换信息量的实质通信需要。因而，不管对于应用 WebRTC 的自研团队，还是提供实时服务的 SDK 服务，尝试修复这个过程中对音频信号引入的伤害，都是必修的课题。
丢包管制
为保障牢靠的实时互动，解决丢包是必须的。如果没有提供间断的音频数据，用户会听到卡顿（glitches、gaps），升高了通话质量和用户体验。
丢包问题能够形象为，如何在不牢靠传输的网络上，实现牢靠传输。通常应用前向纠错 FEC（Forward Error Correction）和 主动重传申请 ARQ（Automatic Repeat-reQuest）两个纠错算法，依据精确的信道状态预计制订相应策略来解决丢包问题。
FEC 是发送端通过信道编码和发送冗余信息，接收端检测丢包，且在不须要重传的前提下依据冗余信息复原失落的大部分数据包。即以更高的信道带宽作为复原丢包的开销。相比 ARQ 的丢包复原，FEC 体验上的延时更小，但因为发送了冗余的数据包，所以信道带宽耗费较多。
ARQ 应用确认信息 ack（acknowledgements signal，即接收端发回的确认信息表征已正确接管数据包）和 timeouts，即如果发送方在超时前没有收到确认信息 ack，则通过滑动窗口协定帮忙发送端决策是否重传数据包，直到发送方收到确认信息 ack 或直到超过事后定义的重传次数。相比 FEC 的丢包复原，ARQ 延时较大（因为要期待 ack 或一直重传），带宽利用率不高。
简略讲，丢包管制中应用的 FEC、ARQ 办法是通过额定的信道带宽，以及延时对失落的数据包进行复原。这就是传统抗丢包办法的现状，那么有什么可行的办法能解决呢？
咱们就以之前开源的 Agora SOLO 为例。通常，编解码器做的事件是压缩、去冗余，而抗丢包从肯定水平上讲是信道解决的扩大化。抗丢包是一种纠错算法的扩大，通过加冗余实现抗丢包。而 Agora SOLO 的策略，是把去冗余和加冗余进行联合，对重点信息加冗余，对非重点信息则更多的去冗余，以达到在信道和信源的联结编码的成果。
延时、抖动管制
数据包在网络传输、排队时自身就会产生提早、抖动。同时，咱们通过丢包管制复原的数据包也会引入延时和抖动，通常应用自适应的 de-jitter buffer 机制进行反抗，确保音频等媒体流间断播放。
正如咱们上文比喻的，数据包提早的变动，咱们称之为抖动（jitter），是一条音频流或其余媒体流数据包之间端到端单向延时的差别。自适应的逻辑是基于数据包达到距离（IAT，inter-arrival times）的延时预计进行决策。当呈现丢包管制未复原的数据包、适度的抖动、延时、突发丢包，即超出自适应缓存可反抗的延时时，就会呈现卡顿。此时接收端个别应用 PLC（Packet Loss Concealment）模块预测新的音频数据，以填充音频数据缺失（因为丢包、适度的抖动和延时引入的丢包、突发丢包）等产生的不间断的音频信号。
综上所述，解决网络伤害，是在不牢靠的通信信道下面，通过丢包、延时、抖动管制办法确保数据包尽可能的程序输入，联合 PLC 预测填充音频数据的缺失。
要尽可能减小网络伤害，须要联合以下五点加强弱网边界：
1. 精确的网络信道状态的预计，动静的对丢包管制的策略进行调整和利用；
2. 以及相配套的 de-jitter buffer，以更快、更准的学习速度适应网络的非稳态（好网络转差，差网络转好，突发的梳状网络）的变动，调整抗抖缓存至大于且更靠近于稳态时等价延时的大小，能力确保收听者在该刹时网络环境下的音质好，延时低，逐步趋于实践最优；
3. 超出弱网可复原边界时，通过降低码率（也罕用来解决信道拥塞），晋升信道带宽中冗余数据或重传次数的开销；
4. 并联合 PLC 对输出信号的适应能力，确保不同谈话者，时变的背景噪声下尽可能的减小可察觉的噪声；
5. 在较小带宽下，通过编码器编码低码率且高质量的语音，联合 3 在网络服务质量差的状况下，减少弱网反抗的鲁棒性。
基于以上在丢包、延时、抖动的反抗策略，咱们就能够基于互联网传输，提供更好的音频实时互动体验。就像咱们之前说的，不同地区、不同时间段、不同网络下，网络的延时、抖动、丢包状况都不同。而声网 Agora SDK 是面向寰球提供高质量的音频交互服务，让寰球各区域的用户在线上进行实时互动，通过音频引擎尽可能将线下的声学体验带给用户。因而咱们也做了屡次实地的测试，并察看 SDK 的 MoS 分（ITU-T P.863）和延时数据体现。
以下是咱们在上海中环环线，应用雷同设施，在雷同运营商网络下，同时测试的 Agora RTC SDK 与友商产品的 MOS 分和延时数据。从统计来看，声网 Agora SDK 提供的实时音频交互服务，在提供较高音质的同时，延时更低。
图：MoS 分比照
图：延时数据比照
能够从 MoS 分比照图看出，Agora SDK 的 MOS 次要散布在高分值 [4.5, 4.7] 区间段，友商次要散布在[3.4, 3.8]。再说一个数据大家可能会有更直观的概念。咱们应用的微信，只管与 RTC SDK 不属于同一类型的产品，但也提供语音通话服务。微信在无弱网环境下测量的最高 MoS 分是 4.19。
用户体验的理论音频品质，可由以下音频品质地图中圆点的色彩显示，绿色示意 MOS 分大于 4.0；黄色示意 MOS 分处于[3.0, 4.0]，红色示意[1, 3.0]。
图：上海中环，Agora SDK 的音频品质
图：上海中环，友商 的音频品质
小结
丢包、延时、抖动是在实时互动场景下不可避免的问题。而且这些问题不仅会因为网络环境、时段、用户设施等因素一直产生变动，也会因为底层技术的倒退而产生新的变动（比方 5G 的大规模利用）。所以咱们针对它们的优化策略也要一直迭代优化。
在追随音频信号从发送端通过网络达到接收端之后，音频体验的优化并没有完结。为了“高音质体验”，咱们还要进一步在端上优化音质，下一篇咱们具体分享其冰山一角，敬请期待。
相干浏览
详解低延时高音质：编解码篇
详解低延时高音质：回声打消与降噪篇