背景与挑战

实时通信（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 的门槛，提高排查、服务的效率。如下图，为无声诊断主要融合的内容。