背景與挑戰
實時通訊（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 提供更多分析和輔助。