教育場景下的實時音頻解決方案

本文來自網易雲信 資深音頻算法工程師 李備在LiveVideoStackCon 2018講師熱身分享，並由LiveVideoStack整理而成。在分享中李備詳細分析了在線教育的音頻需求，以及通常軟件音頻框架，和行業的挑戰。
你們好，我是來自網易雲信的李備，今天我將與你們一塊兒探究教育場景下的實時音頻解決方案。
本次分享將圍繞如下幾部分進行：

1. 實時音視頻的市場需求

1.1 市場觀察
隨着我國互聯網行業的蓬勃發展與寬帶水平的提高，消費者早已不知足於經過簡單的文字圖片瀏覽新聞，而是期待經過更佳生動精彩的音視頻獲取知識瞭解世界。根據網易雲信平臺觀測的數據，音視頻社交應用時長在近兩年呈現飛速增加，隨之增加的一樣還有中國在線教育市場交易規模，從2010年至2017年增加近10倍，並預計在2018～2019年保持增加。
能夠說，實時音視頻技術助力衆多產業轉型升級，並使得視頻會議等經典應用場景重獲新生。衆多的新興場景與行業藉助實時音視頻技術實現了更佳豐富炫目高效準確的場景表達與業務落地，同時也進一步促進了實時音視頻的技術演進與行業探索。實時音視頻正在各個千億、百億市場快速發展並逐漸成爲基礎設施型重要技術。
1.2 應用場景

咱們的音視頻行業主要存在如下應用場景：以網易公開課爲表明的點播，以Finger爲表明的直播，以網易雲課堂爲表明的互動直播與以各類P2P、小班教學、大型培訓爲表明的實時音視頻。

1.3 直播/點播框架
下圖展現的是直播與點播的技術框架。

而與上述直播/點播框架不一樣的是，互動直播框架更增強調音視頻的實時性與強互動性。
來自Web 端連麥觀衆的音頻數據會經過WebRTC網關傳輸至實時音視頻中轉服務器，並在此與來自手機連麥觀衆和PC端主播的音視頻數據一塊兒由實時音視頻中轉服務器轉發至互動直播服務器。
互動直播服務器會對這些數據作合成/推流處理，傳輸至融合CDN流媒體服務器，由流媒體服務器推送數據給觀看互動直播的普通觀衆。
與此同時，實時音視頻中轉服務器一樣負責手機連麥觀衆與PC端主播的直播互動數據交換，從而實現互動直播的效果。

1. 軟件層實時音頻解決方案

2.1 實時音框架的線程模型與數據驅動方式

上圖展現的是實時音頻的簡單框架線程模型，這裏須要提醒的是，其中的解碼主要由客戶端完成，實時音的服務端不參加解碼而是把來自各端的數據包篩選以後傳遞給其餘端。
咱們以音樂教學場景爲例，學生與老師正在上課，此時來自學生的音頻信號被其移動終端採集模塊採集，通過混音消除、降噪、自動增益控制等音頻的前處理過程，由音頻編碼器進行編碼。
這裏的編碼器主要分爲專屬語音編碼器與音樂編碼器。音頻數據通過編碼器的編碼處理後會被髮送至網絡，此時接收端會收到一個緩衝抵抗網絡抖動的Jitter Buffer。解碼後的音頻數據通過快慢速調製與TSM後進行後處理，最後播放。播放時產生的回聲會被捕捉並重覆上述流程。
在硬件層面，終端製造商對音頻處理流程中所須要的硬件都有一套同一切完善的參數調整經驗，例如麥克風的採集幀率、拾音距離、回聲延遲等都有統一規範；而考慮軟件層面的實時音頻則需面臨設備數量龐大的難題，咱們須要統一海量設備與不一樣平臺的複雜數據輸入而且考慮到軟件層面的不可預知性，也就是咱們須要一個完善的音頻處理系統，優化各模塊之間的協同工做並保證算法的穩定性。所以在這裏我向你們展現一下WebRTC線程模型的設計和數據驅動方式：不一樣的顏色表明不一樣的線程。
首先，音頻數據被採集模塊採集後進行音頻前處理，以後經由交付Buffer被交至音頻Codec進行編碼。（這裏強調的是，咱們不把音頻Buffer和Codec放在一個線程的緣由是音頻Codec的實時性計算量要求較高，須要單獨的一個線程運行。而通過網絡發送時通常網絡線程是直接將數據傳輸至Audio Jitter Buff-er，Audio Jitter Buffer獲取數據後會在網絡線程上接收數據包，並更新網絡統計和策略，而playback的callback請求往上回調至Audio Jitter Buffer請求數據過程是運行在Playback的Callback線程上。
通過解碼後音頻數據會進行TSM、MIX等（若是是處理多路MIX，有些廠家可能會使音頻解碼單獨在一個線程上運行，這一點視應用場景而定，若是是處理一路MIX則能夠簡單地運行在播放線程上。）關於其中的驅動方式，一些開發者喜歡使用Timer機制驅動數據，但這在實時音頻框架中並不推薦。以Audio三維算法處理爲例，音頻每一幀處理須要大約10毫秒的時間，對時間的精度要求很高；而簡單的Timer驅動沒法知足這種高精度，尤爲是在複雜的系統中很容易出現延遲，這爲整個音頻處理系統帶來的影響無疑是毀滅性的。所以咱們通常採起將驅動運行在系統（回調）中的解決方案，由於系統（回調）的高優先級可確保整個系統的穩定運行。Google就曾經在I/O大會上面推薦把audio process放到系統的採集播放線程裏 ；右側展現的主要有兩個系統：收包網絡系統與底層的用來驅動音頻解碼、後處理、MIX的Playback。一個音頻引擎框架的穩定性直接決定了其輸出聲音的質量與實時性。
2.2 音頻前處理框架

捕捉到的音頻數據會進入Audio 3A處理。其中Audio 3A由AEC、ANS、AGC組成。不一樣的應用場景三者的處理順序也不一樣，如在WebRTC中音頻數據回依次通過AEC和NS 或者 NS 與AECM（AECM 是WebRTC專門爲移動端打造的算法，計算量低，而AEC 是爲PC打造的）。
而在AEC(回聲消除算法)，爲何須要這個算法呢？當一個設備在播放聲音通過空間中的屢次反射會被麥克風再次捕捉並採集到系統當中，這時音頻的輸入既有空間反射的回聲也有本端說話聲，若是缺乏此模塊就意味着通話中說話人一直能夠聽到本身的聲音回來，這是很是差的一種體驗，這固然是須要咱們避免的。
這裏AEC的做用就是經過播放的參考信號跟蹤出回聲並從採集信號中把回聲消除掉，隨後再通過降噪處理去除噪聲。而其中的AECM是在NS模塊以後經過獲取clean與noise數據進行分析，AEC則是NS模塊以前直接獲取noise數據進行分析。音頻數據完成AEC與NS的處理後會進行AGC處理，其包括AAGC（模擬域的自動增益控制）與DAGC（數字域的自動增益控制）。
其中AAGC的主要做用是經過系統的採集音量設置接口調整輸入信號（大多用於PC端，移動端通常沒有輸入音量的系統接口），如藉助Windows上的的API調整採集音量等參數。AAGC可爲輸入的音頻數據帶來明顯的質量優化，如提升信噪比，避免輸入信號溢出等。但因爲咱們服務的跨平臺要求，咱們須要構建一個面向多平臺設備的框架，在不一樣的輸入平臺和設備都會有不一樣的輸入音量，DAGC能夠根據對輸入信號的跟蹤，儘可能的調整信號到達指望大小(幅值或能量)，從而避免不一樣設備採集帶來的音量差別過大。完成AGC處理的音頻數據，便可進入Audio Encode進行編碼操做。

這裏我想特別介紹一下Audio Jitter Buffer，因爲視頻的發送碼率較高容易對網絡形成較大沖擊比較大，而音頻在窄帶與中等碼率的情景下的發送碼率在50KBPS上下，不會爲網絡帶來較大壓力，不少廠家在作音頻QOS的時候並不會控制發送帶寬(由於寬帶的音頻帶寬不高，對於網絡擁塞貢獻不大)，而把重點工做都放在接收端的jitter buffer策略上。但咱們的人耳對連續性很是敏感，一旦有包沒能及時傳遞出現丟包，那麼觀衆就可體驗到瞬間的卡頓，這種頻繁的卡頓會讓用戶體驗大打折扣。
所以咱們須要一個抵抗抖動的Buffer來抵抗網絡抖動的衝擊，從對Delay要求高、平滑穩定過渡的角度考慮咱們但願選擇較長的Buffer，而從實時性出發咱們又但願儘量縮短buffer。
爲了平衡網絡抖動與實時性，咱們引入Audio Jitter Buffer進行處理。通常用來在接收端控制網絡抖動，而在不一樣模式下采起的抗抖動方案也不盡相同。Jitter Buffer框架與其包含的模塊展現在這張圖中，其中黃色表明網絡線程。Audio Play Callback的數據首先傳輸至Manager，同時上傳一些必要信息，此時音頻數據會通過Jitter Policy處理傳輸至Audio Decode並在播放端觸發callback，再由Callback驅動整個抓包流程。JitterBuffer請求包時會根據Jitter Policy進行音頻解碼或PLC/CNG、Slience等。最後通過後處理與MIX的反覆處理，數據被傳輸至Audio Play Callback。
不一樣廠商的Jitter Policy處理方案也不同，如較爲出名的WebRTC NeTEQ算法，其中集成了自適應抖動控制算法以及語音包丟失隱藏算法。除此以外， JitterBuffer在跟蹤預測準每個包的jitter的時候，也須要考慮實際的緩存播放策略，好比三個包的jitter 分別是100ms，50ms和150ms，若是每次都緊跟預測的jitter，當第一個包來的時候須要緩存100ms，而後第二個包來的時候發現只須要緩存50ms，實際緩存多了須要TSM 調整，直到第三個包來，發現要緩存的又要變化了，又須要須要TSM 調整，那麼這樣最後的效果將是很是糟糕的。JitterBuffer的目標就是緩存適合的數據能夠抵抗網絡jitter的抖動，自適應既要兼顧考慮時延，又不能變化過於頻繁破壞聲音體驗，也不能不跟不上網絡變化形成緩存不足形成丟包。

1. 行業痛點

音頻行業之痛主要是複雜的網絡對音頻的衝擊與碎片化的終端設備背後差距懸殊的硬件。尤爲是對Android平臺而言，軟件層面不一樣廠家定製系統的處理流程、硬件層面手機的工業設計、處理器、傳感器等都不相同，難以用統一的平臺解決方案處理這些設備的音視頻問題，主要體如今算法的挑戰難度上；與此同時，咱們但願算法魯棒性更強，這就意味着須要考慮更多的案例，而算法不可能考慮到全部的案例，咱們必須根據實際狀況進行相應取捨……這些都是在將來亟待解決的行業痛點。

想要閱讀更多技術乾貨文章，歡迎關注網易雲信博客。
瞭解網易雲信，來自網易核心架構的通訊與視頻雲服務。

網易雲信（NeteaseYunXin）是集網易18年IM以及音視頻技術打造的PaaS服務產品，來自網易核心技術架構的通訊與視頻雲服務，穩定易用且功能全面，致力於提供全球領先的技術能力和場景化解決方案。開發者經過集成客戶端SDK和雲端OPEN API，便可快速實現包含IM、音視頻通話、直播、點播、互動白板、短信等功能。