年初因爲工作需要，開始學習WebRTC，就被其複雜的編譯環境和巨大的代碼量所折服，註定是一塊難啃的骨頭。俗話說萬事開頭難，堅持一個恆心，終究能學習到WebRTC的設計精髓。今天和大家聊聊WebRTC中音頻的那些事。WebRTC由語音引擎，視頻引擎和網絡傳輸三大模塊組成，其中語音引擎是WebRTC中最具價值的技術之一，實現了音頻數據的採集、前處理、編碼、發送、接受、解碼、混音、後處理、播放等一系列處理流程。
音頻引擎主要包含：音頻設備模塊ADM、音頻編碼器工廠、音頻解碼器工廠、混音器Mixer、音頻前處理APM。
音頻工作機制
想要系統的瞭解音頻引擎，首先需要了解核心的實現類和音頻數據流向，接下來我們將簡單的分析一下。
音頻引擎核心類圖：
音頻引擎WebrtcVoiceEngine主要包含音頻設備模塊AudioDeviceModule、音頻混音器AudioMixer、音頻3A處理器AudioProcessing、音頻管理類AudioState、音頻編碼器工廠AudioEncodeFactory、音頻解碼器工廠AudioDecodeFactory、語音媒體通道包含發送和接受等。
1.音頻設備模塊AudioDeviceModule主要負責硬件設備層，包括音頻數據的採集和播放，以及硬件設備的相關操作。
2.音頻混音器AudioMixer主要負責音頻發送數據的混音（設備採集和伴音的混音）、音頻播放數據的混音（多路接受音頻和伴音的混音）。
3.音頻3A處理器AudioProcessing主要負責音頻採集數據的前處理，包含回聲消除AEC、自動增益控制AGC、噪聲抑制NS。APM分爲兩個流，一個近端流，一個遠端流。近端（Near-end）流是指從麥克風進入的數據；遠端（Far-end）流是指接收到的數據。
4.音頻管理類AudioState包含音頻設備模塊ADM、音頻前處理模塊APM、音頻混音器Mixer以及數據流轉中心AudioTransportImpl。
5.音頻編碼器工廠AudioEncodeFactory包含了Opus、iSAC、G711、G722、iLBC、L16等codec。
6.音頻解碼器工廠AudioDecodeFactory包含了Opus、iSAC、G711、G722、iLBC、L16等codec。
音頻的工作流程圖：
1.發起端通過麥克風進行聲音採集
2.發起端將採集到的聲音信號輸送給APM模塊，進行回聲消除AEC，噪音抑制NS，自動增益控制處理AGC
3.發起端將處理之後的數據輸送給編碼器進行語音壓縮編碼
4.發起端將編碼後的數據通過RtpRtcp傳輸模塊發送，通過Internet網路傳輸到接收端
5.接收端接受網絡傳輸過來的音頻數據，先輸送給NetEQ模塊進行抖動消除，丟包隱藏解碼等操作
6.接收端將處理過後的音頻數據送入聲卡設備進行播放
NetEQ模塊是Webrtc語音引擎中的核心模塊
在 NetEQ 模塊中，又被大致分爲 MCU模塊和 DSP 模塊。MCU 主要負責做延時及抖動的計算統計，並生成對應的控制命令。而 DSP 模塊負責接收並根據 MCU 的控制命令進行對應的數據包處理，並傳輸給下一個環節。
音頻數據流向
根據上面介紹的音頻工作流程圖，我們將繼續細化一下音頻的數據流向。將會重點介紹一下數據流轉中心AudioTransportImpl在整個環節中扮演的重要角色。
數據流轉中心AudioTransportImpl實現了採集數據處理接口RecordDataIsAvailbale和播放數據處理接口NeedMorePlayData。RecordDataIsAvailbale負責採集音頻數據的處理和將其分發到所有的發送Streams。NeedMorePlayData負責混音所有接收到的Streams，然後輸送給APM作爲一路參考信號處理，最後將其重採樣到請求輸出的採樣率。
RecordDataIsAvailbale內部主要流程：
- 由硬件採集過來的音頻數據，直接重採樣到發送採樣率
- 由音頻前處理針對重採樣之後的音頻數據進行3A處理
- VAD處理
- 數字增益調整採集音量
- 音頻數據回調外部進行外部前處理
- 混音發送端所有需要發送的音頻數據，包括採集的數據和伴音的數據
- 計算音頻數據的能量值
- 將其分發到所有的發送Streams
NeedMorePlayData內部主要流程：
- 混音所有接收到的Streams的音頻數據
1.1 計算輸出採樣率CalculateOutputFrequency()
1.2 從Source收集音頻數據GetAudioFromSources(),選取沒有mute，且能量最大的三路進行混音
1.3 執行混音操作FrameCombiner::Combine()
- 特定條件下，進行噪聲注入，用於採集側作爲參考信號
- 對本地伴音進行混音操作
- 數字增益調整播放音量
- 音頻數據回調外部進行外部前處理
- 計算音頻數據的能量值
- 將音頻重採樣到請求輸出的採樣率
- 將音頻數據輸送給APM作爲一路參考信號處理
由上圖的數據流向發現，爲什麼需要FineAudioBuffer和AudioDeviceBuffer？因爲WebRTC 的音頻流水線只支持處理 10 ms 的數據，不同的操作系統平臺提供了不同的採集和播放時長的音頻數據，不同的採樣率也會提供不同時長的數據。例如iOS上，16K採樣率會提供8ms的音頻數據128幀；8K採樣率會提供16ms的音頻數據128幀；48K採樣率會提供10.67ms的音頻數據512幀。
AudioDeviceModule 播放和採集的數據，總會通過 AudioDeviceBuffer 拿進來或者送出去 10 ms 的音頻數據。對於不支持採集和播放 10 ms 音頻數據的平臺，在平臺的 AudioDeviceModule 和 AudioDeviceBuffer 還會插入一個 FineAudioBuffer，用於將平臺的音頻數據格式轉換爲 10 ms 的 WebRTC 能處理的音頻幀。在AudioDeviceBuffer 中，還會10s定時統計一下當前硬件設備過來的音頻數據對應的採樣點個數和採樣率，可以用於檢測當前硬件的一個工作狀態。
音頻相關改動
1.音頻Profile的實現，支持Voip和Music 2種場景，實現了採樣率、編碼碼率、編碼模式、聲道數的綜合性技術策略。
iOS實現了採集和播放線程的分離，支持雙聲道的播放。
2. 音頻3A參數的兼容性下發適配方案。
3.耳機場景的適配，藍牙耳機和普通耳機的適配，動態3A切換適配。
4.Noise_Injection噪聲注入算法，作爲一路參考信號，在耳機場景的回聲消除中的作用特別明顯。
5.支持本地伴音文件file和網絡伴音文件http&https。
6.Audio Nack的實現，提高音頻的抗丟包能力，目前正在進行In-band FEC。
7.音頻處理在單講和雙講方面的優化。
8.iOS在Built-In AGC方面的研究：
- Built-In AGC對於Speech和Music有效，對於noise和環境底噪不會產生作用。
- 不同機型的麥克風硬件的增益不同，iPhone 7 Plus > iPhone 8 > iPhone X;因此會在軟件AGC和硬件AGC都關閉的情況下，遠端聽到的聲音大小表現不一樣。
- iOS除了提供的可開關的AGC以外，還有一個AGC會一直工作，對信號的level進行微調；猜想這個一直工作的AGC是iOS自帶的analog AGC，可能和硬件有關，且沒有API可以開關，而可開關的AGC是一個digital AGC。
- 在大部分iOS機型上，外放模式“耳機再次插入後”，input的音量會變小。當前的解決方案是在耳機再次插入後，增加一個preGain來把輸入的音量拉回正常值。
音頻問題排查
和大家分享一下音頻最常見的一些現象以及原因：
更多技術乾貨，歡迎關注vx公衆號“網易智慧企業技術+”。系列課程提前看，精品禮物免費得，還可直接對話CTO。
聽網易CTO講述前沿觀察，看最有價值技術乾貨，學網易最新實踐經驗。網易智慧企業技術+，陪你從思考者成長爲技術專家。