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