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