年初因為工作需要，開始學習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講述前沿觀察，看最有價值技術干貨，學網易最新實踐經驗。網易智慧企業技術+，陪你從思考者成長為技術專家。

總結

以上是生活随笔為你收集整理的WebRTC系列之音频的那些事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。