大数跨境
0
0

RTE2021 回顾丨实时语音活动背后的质量监控

RTE2021 回顾丨实时语音活动背后的质量监控 RTE开发者社区
2021-11-19
0
导读:如何实现无参的实时音频 QoE 评估

本文整理自声网Agora 音频算法工程师赵晓涵在 RTE 2021 实时互联网大会上的演讲分享。在演讲中他主要介绍了声网实时语音质量监控系统领域的发展历程、目前所做项目过程中的一些想法和进展以及对未来规划的一些展望。


▲图:声网Agora 音频算法工程师赵晓涵




赵晓涵提到语音质量评估大概经历了二三十年的发展,其方法主要分为三大类:


客观的有参考:最早是 1996 年的 P.861 (PSQM),它的提出是为了评估一些 4K 采样率编解码器的性能。2001 年ITU.T推出了 P.862 (PESQ) ,该方法目前应用最为广泛。在 2011 年,P.863 (POLQA) 被提出。相比 PESQ,POLQA 可评估的带宽更广,也是目前最先进的客观有参考评价方法。


客观的无参考:2003 年提出的 E-Model 方法是基于整个传输链路的一些状态,比如丢包或者延时。更多的无参考算法还是从信号本身出发去做分析,应用较为广泛的是 2004 年提出的 P.563。它通过对信号的自然度、流畅度以及噪声情况,进行一个整体估计,然后给出一个意见分数。到了 2006 年左右, ANIQUE+方法被提了出来,此时文献里对标的是有参考的 PESQ 的精度,并且证明它的精度会超过有参考评估方法 PESQ。随着深度学习的广泛应用,出现了基于深度学习语音质量信号的评估方法,通常称之为 XXnet。这种方法已经不仅局限于测评一些能力了,也开始测评一些降噪后的信号质量。


主观:由 P.800 定义了 MOS 这个概念之后,后面只提出了一些特定领域或方向的测试方法,大的方法论没有变化。 


由此,可以发现语音质量评估的发展趋势有两个:


实时化:近十年来,主要的一些技术进展更多的是出现在无参考质量评估领域。在部分场景下,无参考的质量评估方法已经达到甚至超过了有参考的质量评估的方法,这也给赵晓涵团队做一个实时的语音质量评估带来了更高的可能性。


多维化:从最早的只能测评一个 4K 有效频谱的性能,到测评一个全带的性能,再到能够测评降噪的一些能力。赵晓涵团队发现整个语音质量评估的方法也可以从单一的小模块,逐渐扩展到整个 Pipeline。




基于以上观察,声网大约于去年年中开始了一个在线语音质量评估项目,项目的出发点有两个:


通话质量是什么:我们可以看到线上通话的状态信息,例如丢帧率、卡帧率、延时,但是无法清楚地说明通话质量的状态。


版本质量的把控:声网 SDK 的版本经过了 QA、Lab 的验收之后,将其发布到线上,其中的表现如何,可能在很长一段时间内都只能前线的工程师或客户来对其反馈。


带着这两个出发点,音频团队开始了在线语音质量监控的项目。 


在项目开始阶段,即方法的预研阶段,我们尝试把 P.563 做了一个实时工程化,用它去真正地测评一些我们通话中的一些 case,然后发现它的质量、精度或鲁棒性是难以达到预期的。


基于这些考虑,声网最后决定来做一套真正符合其需求,并且符合其架构的一套评估系统。这套系统的核心思想就是以现有的算法状态为核心,减少额外的算力引入。声网基于现有的算法状态建立了若干个观测矩阵,对算法状态和体验做实时的映射。



声网设计了一套架构:在端到端的通话中,在采集端会有一个单独的上行质量评估模块,这个模块是用来评估诸如回声、噪声、有无杂音或者是否为奇怪的输入信号。在接收端声网还部署了一个下行的质量监测模块,主要是用来评估编解码的损伤、网络引入的损伤,以及弱网对抗模块带来的增益。


上行质量评估模块会将评估分数一起发给下行端,下行端还有一个质量整合模块,它会根据当前的混音模式,以及一些能量的状态,计算出此时在接收端后面的人的真实体验状况。


上行质量评估模块和下行质量监测模块都会将评估分数上传给数据中台,数据中台会做进一步的多维分析以及跟进的解释。


简单地把上行的质量评估模块与下行的质量监测模块串联起来,大致的架构流程如图所示。



可以发现,从音频采集开始到 AEC、NS,以及一些杂音的检测模块、编码模块,再到弱网对抗、混音、模仿,每个点都预埋了一个监控模块,从而持续地探测这个关键节点的质量,一旦发现问题,异常上报模块就会被触发,最后输出给数据后台。




在线语音质量评估项目的研究涉及了很多处理环节,在此赵晓涵分享了一些比较重要的经验。


回声相关方面,主要是延时抖动或者是不匹配、幅值溢出、其他。


其中,延时抖动是引起回声最大的一个因素。导致延时抖动的 case 很多,例如双设备、设备非线性严重或者多线程协作的不匹配,都会引起延时抖动。


幅值溢出更多的会导致 AEC 线性滤波器 error 的迅速增长,从而需要进行自我更新,导致回声泄露。


其他方面最常见的是混响和双讲。如果混响长度超过了滤波器的长度,就可能会泄漏回声。双讲对单 case 的好坏在当前节点比较难判断,目前是通过了一些基于经验的逻辑方法去做双讲的损伤判断。


噪声相关方面,主要是输入性的噪声,包括稳态噪声或瞬态噪声;以及自激性噪声。


目前传统的信号处理可以很好地做一些噪声消除,不会引起一个明显的质量失真。对人的心理影响更大的其实是瞬态的噪声,即突发噪声。它的特征是出现在各个频段,不同频段的噪声对人的心理会带来不同的影响。


自激性噪声来自于通话本身,如果把通话中断或者是挂断,噪声就不存在了。由于这种噪声就来自于人本身的行为,所以它对人的心理的影响是最大的。


在生活中最常见的自激性噪声是啸叫,一般又指近场啸叫。这也是我们需要密切去监控、关注的一个方面,对于这种来自于通话本身,体验又非常差的 case,如果使用声网的监测模块监测出来,再与算法模块进行交互,可以让信号去处理这个 case。


针对整体噪声影响的评估,声网团队提出了解决方案:


声网训练了一个模型,用来和人的主观打分做拟合,由于这个模型比较大,目前还没有部署在线上,而是在线下测评降噪的能力。声网在线上运行了一个小模型,把噪声的分布映射到了不同的bark域上,再根据映射结果做了一个线性回归。虽然线上模型的精度没有线下模型的好,但是对在线质量评估而言也足够。


传输相关方面,因为它可以同时作用在清晰度和流畅度上,所以它最影响整个通话体验。在评估时,编解码器、网络质量、弱网对抗能力是紧密耦合在一起的。


在 AI Codec 出来之前,各个编码框架已经基本固定成熟了,不同的框架在不同的码率下处理不同的信号,性能也不同。这些可以当做一个先验知识加入到整个语音质量评估的一个链路中去。


网络质量可以和弱网对抗能力一起谈,像延时、丢包和抖动老三样在很多年前就被谈及了。网络延时和弱网对抗能力可以理解为互相打架的两个人,谁占上风谁就对质量有了话语权。


弱网对抗能力是由 ARQ、FEC、PLC 等算法共同的质量来决定的。实际上,声网音频团队在做整个语音质量监控系统的时候,这些算法会挖掘到更底层的技术细节,会对底层的一些状态进行建模,从而对人的心理做出映射。


其他方面,主要包括混响、设备外放能力、设备采集能力。



混响:一般混响长度小于 30-50 毫秒会被认为是无法感知的,或者可以略微提升愉悦感。如果混响长度超过了 200-300 毫秒,就会对人产生非常坏的影响。


设备外放能力:用手机外放一段音乐,比我们戴耳机听效果会差很多,这是和手机上搭载的音乐能力有关,一般越便宜的设备其功放能力越差。简单来讲,可以通过估计设备功放的非线性程度,来估计当前设备的播放能力。


设备采集能力:一般手机或者设备的内置麦克风没有什么问题,真正问题比较多的可能是蓝牙,尤其是连接着像 HFP、SCO 的蓝牙,它们有自己的信号处理,蓝牙的功耗也比较低,所以信号处理的复杂度不会变得很高,很多蓝牙处理可能会起到适得其反的作用。对蓝牙能力的监测、对单一通话的无参考采集能力是比较困难的,可以利用一些大数据的方法,对某一款蓝牙设备进行质量监控。


数据分析和存储方面,主要包含以下三个方面:


端云融合:端上是距离“事发现场”最近的一个地方,可以拿到所有的状态信息。声网没有把大部分的信息都做一个上报,而是先在端上形成一些半结论性的数据,再输出给数据中台。数据中台只需要把半结论性的数据进行二次分析或者多维分析,就可以输出多维度分析结论。


存储切片化:如果数据量很大,即使只上传半结论性的数据至服务器,整个存储成本依然很高。于是,赵晓涵团队在存储成本方面对数据进行时序切片化,声网不会存储所有半结论性数据,而是以切片化的结论作为存储的介质,这样后续的计算成本和存储成本都可以接近百倍的下降。


预警实时化:在后台拿到数据之后,声网会做一个实时的数据分析,通过机器学习的模型对整个通话的质量做预估。如果该模型认为通话异常,就会进行实时告警。




赵晓涵团队在线下完成了质量评估打分对齐,即在各个环境下建立通话,使用 POLQA 和声网的打分系统分别打分。目前的 MAE 是小于 0.1 分的,最大的误差只有 0.15 分。在一定程度上,声网认为这套在线质量评估系统是准确的。(由于 POLQA 系统不能监测回声质量,同时本身自带一个降噪算法,对于带噪信号的评估是不准确的。因此,在真正测评时,输入信号是不包含回声和噪声的)


基于这样一套系统,在每段通话结束之后可以给它进行打分,这个分数可以跟线下实验室的打分对齐,这样就可以回答项目的第一个出发点,即线上用户的通话质量是什么。


下图是声网在一段时间内对全网的质量做了一个监控的结果展示,左边的分数表示他们目前在全网平均的得分是 4.54 分,离 4.75 分的满分还有 0.2 分左右的差距,这也是后续优化算法的一个方向。



声网对每个客户也建立了端到端的监控,这个监控包括每个模块正常与否的监控。若发现某个客户整体的质量出现了明显的下降,则认为他的某个模块出现了问题,由此可以快速定位问题,快速进行版本的迭代。


另外,如果声网想知道当前市面所有的设备,比如哪些设备对回声消除最有力,哪些不利于回声消除。一般会在某一个时间节点朝引擎里投放一些种子指标,一段时间后,通过后台的挖掘分析,可以找到那些真正对回声消除不利的设备,从而做针对性的调优。同时,会对各个单项体验的 case 也有全盘的监控。


版本质量横向的监控有很多,下图展示的是其中一个。



通过对版本之间的横向监控,赵晓涵团队逐渐建立起了信心。目前在内部测量出来没有问题的版本,到线上也不会出现明显的问题。一旦有版本出现异常的波动,就会立刻发现,并且可以通过一些云端的控制策略进行调整。


声网音频团队所使用的框架在设计初期是增量可裁减的,所以它的架构灵活度非常高,可以实时添加一些因子。团队会继续沿着这套框架去补充更多的因子。



此外,在做这个项目的时候,声网发现目前音频的这个领域,可能缺少一些体验上的量化,比如回声的主观体验是什么,现在也只能通过很少的文献或者一些实验室的网站找到一些结论。声网希望可以把这方面完善起来,以促进音频行业的发展。



【声明】内容源于网络
0
0
RTE开发者社区
RTE 开发者社区是聚焦实时互动领域的中立开发者社区。不止于纯粹的技术交流,我们相信开发者具备更加丰盈的个体价值。行业发展变革、开发者职涯发展、技术创业创新资源,我们将陪跑开发者,共享、共建、共成长。
内容 1122
粉丝 0
RTE开发者社区 RTE 开发者社区是聚焦实时互动领域的中立开发者社区。不止于纯粹的技术交流,我们相信开发者具备更加丰盈的个体价值。行业发展变革、开发者职涯发展、技术创业创新资源,我们将陪跑开发者,共享、共建、共成长。
总阅读1.4k
粉丝0
内容1.1k