实时通信(Real-Time Communication,RTC)音频技术是指将音频流实时传输到远程用户的技术,满足线上实时交互的诉求,广泛应用于在线教育、视频会议、直播、泛娱乐社交、金融、医疗、政企等场景。在 RTC PaaS 厂商实际开发、运营中,音频问题场景多样性、问题迥异性、问题定位时效性对 RTC 音频问题的排查带来了诸多挑战。
RTC 音频问题排查,是 RTC 音频开发技术、功能演进的日常,也是 RTC 音频 QA 的日常,更是 RTC 音频服务的日常。如何在繁杂的事务中,梳理出框架和效率工具,服务降本增效、提高 RTC 音频服务满意度,是本文探讨的重点。
音频问题排查 音频问题常见表现常见的音频问题,如下:
这些问题会严重影响用户体验,甚至导致通信无法正常进行。
音频问题的主要特点1. 音频问题随机性大。
RTC 语音是实时交互的语音通信技术,其通过网络传输。网络环境有 2G、3G、4G、5G、Wi-Fi 等不同通信标准,不同运营商、不同区域、不同洲际等差异,网络状况会受到拥堵、丢包、网络延迟等问题的影响。网络波动的必然性, 还有设备使用场景的随机性,决定语音问题出现的随机性。
2. 多平台设备差异大。
RTC 音频需要支持多种设备和平台,包括 Windows、Android, iOS、Mac,IoT 等。不同设备的硬件还有操作系统的差异、以及附件的差异,例如蓝牙耳机、声卡、模拟器等。
3. 同一个表象,不同根因,定位难。
同样杂音问题,可以是网络差导致传输数据包丢失或乱序导致的杂音。还有可能是设备 CPU 负荷很高时,录、播线程调度不及时,也会导致杂音。NS 的抑噪算法可能存在问题,导致抑制噪声不彻底,反而产生杂音。产生杂音的原因远远不止这几个可能。可见,实时语音的问题很难去定位。
4. 音频体验问题多。
RTC 音频传递的不仅是声音信息也传递声音所蕴含的情感。人们对音频问题容忍度非常低。用户在使用 RTC 服务时,需要保证高质量的声音传输,包括低延迟、高保真、稳定性和可靠性等方面。
音频问题处理的流程如下图,可以明确看到 RTC 音频问题的来源、排查主体、排查的处理形式。
音频问题排查的主要痛点1. 数据获取困难性。
RTC 是实时传输,问题也是实时出现的。收到问题反馈的时间,几乎都是延后的。得到音频问题的详细数据很关键,也有一定的难度,例如无法获取原始音频数据、无法重现问题等。
2. 排查流程复杂性。
音频问题排查的流程比较复杂,需要涉及多个环节,例如数据采集(ADM)、数据处理(APM)、编解码器(ACM)、网络(ANM)、服务器、用户所处场景等。
3. 技术门槛高。
音频问题排查需要掌握一定的音频处理和信号处理知识,内部排查工具也有一定的学习、使用成本,对排查人员的要求较高。
4. 问题多元、碎片化。
音频问题可能具有多样性和复杂性,例如回声、噪音、失真等问题,需要针对不同情况采用不同的排查方法;同样的问题,根因随着硬件、场景等变化而变化。
因此,在音频问题排查过程中,需要充分了解问题的特点和具体情况,采用合适的工具和方法进行排查,同时需要具备较高的技术水平和问题解决能力。在如何改进工具和方法、降低音频问题排查门槛、提高解决问题能力等方面, 云信 RTC 团队做了一些探索和实践。
云信 RTC 音频问题排查实践音频问题排查着力点如下图,我们以音频问题处理流程标准化、自动化为提升排查效率的着力点。
音频问题处理流程标准化如下图,从 5 个方面来完成音频问题处理流程标准化的闭环。
1. 音频的数据流、控制流清晰化。
RTC PaaS 本质是流媒体传输,通过 API 融入不同实时场景,完成实时交互。对于排查问题者,需要抓住不变的部分:数据流和控制流。并从这 2 个维度来剖析问题。云信 RTC SDK 根据多客户、多场景改进并清晰化 SDK 音频数据流和控制流。
2. RTC QS 易用性、友好性改进。
业界普遍具备实时事件、实时指标的上报,以方便调查可能有问题的任意一通会话。QS 是云信 RTC 查看每一通会话时都会用到的调查工具。以用户少操作、所见即所得的方式展示 QS 数据,以频道中的 uid 为中心汇聚数据,在提供的 E2E 页面,配置各个模块问题调查的快速切换,让用户使用快速上手、快速查。
4. 传递 RTC 音频知识。
分享 SDK 音频数据流、控制流,QS 工具排查音频问题的主要办法、案例;总结场景系统问题、音频场景推荐配置、各类问题主要排查思路等。
5. 监控问题进展和瓶颈。
问题排查以 JIRA 流转的方式,在内部形成处理闭环。对音频 JIRA 监控,推进问题生命周期转化,以及为判断资源调配提供数据支撑。
音频问题排查自动化实践QS 工具及相关配套 RTC 基础设施一起完成了 RTC 数据收集、分类与聚合、数据检索等。如何从巨大的 RTC 音频数据里发掘信息,服务于理解和解决问题,便成为团队要完成的命题。
1. 音频问题自动感知
音频问题感知是以主动识别音频引擎问题为出发点,实现主动感知、发现问题,从整体上反馈出突出问题,指明优化方向,从而更迅速的实现改进。
设备/无声异常感知
音频录、播状态映射了 SDK 设备、无声状况。设备/无声异常的梳理维度和时间维度,外加 AppId,SDK 等可选维度,可反映某个 Appkey 或 SDK 在无声问题上的稳定程度和趋势性。
音量小感知
音量对音质的影响是显著的,在其他条件一致的情况下,音量越大,主观听感越好。讲话者说话声音洪亮,在一定程度上能提升听音者的可懂度。
如上图,音量主要跟设备、APM 处理等相关。感知设备采集音量小,发送音量小等,呈现 APM 处理整体效果、感知音量小导致无声等问题。
录/播频率不稳感知
录、播频率的平稳性直接跟音频体验强相关。在频道内除正常 ADM 重启(例如,录音与不录音间变化、硬件 AEC 与软件 AEC 间切换,路由变化等)导致短暂频率不平稳外,感知其它频率不平稳的情况,为音频卡顿等感知和体验优化提供依据。
回声感知
回声消除是 RTC 链路中比较重要的一个模块,回声处理好坏不仅跟 AEC 算法先进性相关,也与设备、平台、机型和外接设备有关。回声感知利用音频算法组提供的办法,感知部分长时间漏回声处理的情况。
音频卡顿感知
音频卡顿是指在播放音频时出现的中断或延迟现象,会导致音频听起来不连贯或有间断感。从而降低听众的听取体验。卡顿主要从几个维度完成感知,如下图:
音频延迟大感知
在 RTC 的实时沟通中,延时也是一个非常重要的指标,一般来说,200ms 以内的延时,人的主观感觉无明显的障碍和迟滞感,200ms-400ms 能正常沟通,超过 400ms 就会有迟滞感,更严重时会出现抢话的现象,直接影响通话的体验。在面对面的沟通场景下,时延只有 3ms 左右。延迟大主要从几个维度完成感知,如下图:
音画不同步感知
感知音画不同步目前设计的判断标准如下:
在某会议场景下,目前整体情况如下图:
音频问题感知不仅可以得到相应问题不同时间范围上的趋势、具体客户情况、SDK 版本以及版本间变化情况;也同时感知出异常范围的每一通通话可以直接关联到 QS 等排查工具。UI 布局设计如下图:
与此同时,利用数据平台对各个感知模型挖掘的数据,配置各个数据维度的自动监控并报警。节省人力资源,突出核心重点问题,实现资源效率最大化。自动报警犹如感知的指挥棒,落地数据决策。
2. 音频问题自动诊断
音频问题感知为啥要做音频自动诊断?下图是通过 RTC 实时沟通的两个人,从图上可以看出,讲话者 A 开始说话,声音经过空气传播、麦克风采集、A/D 转换、增强处理(降噪、回声消除、音量控制、去混响)、编码、打包传输、接收端解码、NetEQ、D/A 转换到下行播放,然后 B 听到声音。反之,B 说话声音也是通过相同路径到 A 端。可见问题排查链路的复杂性。
感知出发点是发现音频引擎问题,主动发现问题和解决问题。自动诊断则融合每类问题链路上的多个感知模型,以及客户使用场景,得到某类问题相关的时段、可能原因,为分析具体问题提供了初步的诊断结果。实现减少或无需人工排查 QS,而主动定位问题原因,降低使用 QS 的门槛,提高排查、服务的效率。如下图,为无声诊断主要融合的内容。
某个通话无声诊断结果展示如下:
RTC 音频问题排查展望RTC 音频排查高效化是行业发展的重要课题之一。本文分享了网易云信 RTC 团队在音频问题排查实践中的思考和实践。
虽然 RTC 音频问题排查没有尽头,但在排查和解决音频的思路、策略、工具不断完善的趋势下,问题不断收敛,音频体验不断优化。
音频自动感知、自动诊断系统后续工作重点主要体现在以下几个方面:
几类音频问题的排查系统在实践中迭代演进;
提高系统准确度和敏感度;
自动报警与内部 JIRA 系统的打通;
内部使用到提供面向客户使用的转变;
结合 AIGC 提供更多分析和辅助。