共计 3468 个字符，预计需要花费 9 分钟才能阅读完成。
背景与挑战
实时通信（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 提供更多剖析和辅助。
