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