WebRTC系列之音频的那些事
年初因為工作需要,開始學習WebRTC,就被其復雜的編譯環(huán)境和巨大的代碼量所折服,注定是一塊難啃的骨頭。俗話說萬事開頭難,堅持一個恒心,終究能學習到WebRTC的設計精髓。今天和大家聊聊WebRTC中音頻的那些事。WebRTC由語音引擎,視頻引擎和網絡傳輸三大模塊組成,其中語音引擎是WebRTC中最具價值的技術之一,實現(xiàn)了音頻數(shù)據(jù)的采集、前處理、編碼、發(fā)送、接受、解碼、混音、后處理、播放等一系列處理流程。
音頻引擎主要包含:音頻設備模塊ADM、音頻編碼器工廠、音頻解碼器工廠、混音器Mixer、音頻前處理APM。
?
音頻工作機制
?
想要系統(tǒng)的了解音頻引擎,首先需要了解核心的實現(xiàn)類和音頻數(shù)據(jù)流向,接下來我們將簡單的分析一下。
音頻引擎核心類圖:
?
音頻引擎WebrtcVoiceEngine主要包含音頻設備模塊AudioDeviceModule、音頻混音器AudioMixer、音頻3A處理器AudioProcessing、音頻管理類AudioState、音頻編碼器工廠AudioEncodeFactory、音頻解碼器工廠AudioDecodeFactory、語音媒體通道包含發(fā)送和接受等。
1.音頻設備模塊AudioDeviceModule主要負責硬件設備層,包括音頻數(shù)據(jù)的采集和播放,以及硬件設備的相關操作。
2.音頻混音器AudioMixer主要負責音頻發(fā)送數(shù)據(jù)的混音(設備采集和伴音的混音)、音頻播放數(shù)據(jù)的混音(多路接受音頻和伴音的混音)。
3.音頻3A處理器AudioProcessing主要負責音頻采集數(shù)據(jù)的前處理,包含回聲消除AEC、自動增益控制AGC、噪聲抑制NS。APM分為兩個流,一個近端流,一個遠端流。近端(Near-end)流是指從麥克風進入的數(shù)據(jù);遠端(Far-end)流是指接收到的數(shù)據(jù)。
4.音頻管理類AudioState包含音頻設備模塊ADM、音頻前處理模塊APM、音頻混音器Mixer以及數(shù)據(jù)流轉中心AudioTransportImpl。
5.音頻編碼器工廠AudioEncodeFactory包含了Opus、iSAC、G711、G722、iLBC、L16等codec。
6.音頻解碼器工廠AudioDecodeFactory包含了Opus、iSAC、G711、G722、iLBC、L16等codec。
?
音頻的工作流程圖:
1.發(fā)起端通過麥克風進行聲音采集
2.發(fā)起端將采集到的聲音信號輸送給APM模塊,進行回聲消除AEC,噪音抑制NS,自動增益控制處理AGC
3.發(fā)起端將處理之后的數(shù)據(jù)輸送給編碼器進行語音壓縮編碼
4.發(fā)起端將編碼后的數(shù)據(jù)通過RtpRtcp傳輸模塊發(fā)送,通過Internet網路傳輸?shù)浇邮斩?/span>
5.接收端接受網絡傳輸過來的音頻數(shù)據(jù),先輸送給NetEQ模塊進行抖動消除,丟包隱藏解碼等操作
6.接收端將處理過后的音頻數(shù)據(jù)送入聲卡設備進行播放
?
NetEQ模塊是Webrtc語音引擎中的核心模塊
在 NetEQ 模塊中,又被大致分為 MCU模塊和 DSP 模塊。MCU 主要負責做延時及抖動的計算統(tǒng)計,并生成對應的控制命令。而 DSP 模塊負責接收并根據(jù) MCU 的控制命令進行對應的數(shù)據(jù)包處理,并傳輸給下一個環(huán)節(jié)。
?
?
音頻數(shù)據(jù)流向
根據(jù)上面介紹的音頻工作流程圖,我們將繼續(xù)細化一下音頻的數(shù)據(jù)流向。將會重點介紹一下數(shù)據(jù)流轉中心AudioTransportImpl在整個環(huán)節(jié)中扮演的重要角色。
數(shù)據(jù)流轉中心AudioTransportImpl實現(xiàn)了采集數(shù)據(jù)處理接口RecordDataIsAvailbale和播放數(shù)據(jù)處理接口NeedMorePlayData。RecordDataIsAvailbale負責采集音頻數(shù)據(jù)的處理和將其分發(fā)到所有的發(fā)送Streams。NeedMorePlayData負責混音所有接收到的Streams,然后輸送給APM作為一路參考信號處理,最后將其重采樣到請求輸出的采樣率。
?
RecordDataIsAvailbale內部主要流程:
?
NeedMorePlayData內部主要流程:
?? 1.1 計算輸出采樣率CalculateOutputFrequency()
?? 1.2 從Source收集音頻數(shù)據(jù)GetAudioFromSources(),選取沒有mute,且能量最大的三路進行混音
?? 1.3 執(zhí)行混音操作FrameCombiner::Combine()
由上圖的數(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 拿進來或者送出去 10 ms 的音頻數(shù)據(jù)。對于不支持采集和播放 10 ms 音頻數(shù)據(jù)的平臺,在平臺的 AudioDeviceModule 和 AudioDeviceBuffer 還會插入一個 FineAudioBuffer,用于將平臺的音頻數(shù)據(jù)格式轉換為 10 ms 的 WebRTC 能處理的音頻幀。在AudioDeviceBuffer 中,還會10s定時統(tǒng)計一下當前硬件設備過來的音頻數(shù)據(jù)對應的采樣點個數(shù)和采樣率,可以用于檢測當前硬件的一個工作狀態(tài)。
?
音頻相關改動
1.音頻Profile的實現(xiàn),支持Voip和Music 2種場景,實現(xiàn)了采樣率、編碼碼率、編碼模式、聲道數(shù)的綜合性技術策略。
iOS實現(xiàn)了采集和播放線程的分離,支持雙聲道的播放。
2. 音頻3A參數(shù)的兼容性下發(fā)適配方案。
3.耳機場景的適配,藍牙耳機和普通耳機的適配,動態(tài)3A切換適配。
4.Noise_Injection噪聲注入算法,作為一路參考信號,在耳機場景的回聲消除中的作用特別明顯。
5.支持本地伴音文件file和網絡伴音文件http&https。
6.Audio Nack的實現(xiàn),提高音頻的抗丟包能力,目前正在進行In-band FEC。
7.音頻處理在單講和雙講方面的優(yōu)化。
8.iOS在Built-In AGC方面的研究:
?
音頻問題排查
和大家分享一下音頻最常見的一些現(xiàn)象以及原因:
更多技術干貨,歡迎關注vx公眾號“網易智慧企業(yè)技術+”。系列課程提前看,精品禮物免費得,還可直接對話CTO。
聽網易CTO講述前沿觀察,看最有價值技術干貨,學網易最新實踐經驗。網易智慧企業(yè)技術+,陪你從思考者成長為技術專家。
總結
以上是生活随笔為你收集整理的WebRTC系列之音频的那些事的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Docker文件系统实战
- 下一篇: 知识库成长记