又被「過運營商語音認證」虐了一回

又被「過運營商語音認證」虐了一回！虐的傷痕累累、疲憊不堪！過程是痛苦的，但結果是美好的，收穫也是挺多的！既然用了「又」，那之前確定被虐過。是的，沒錯。那是7年多前（2011年末），一樣是在秋冬，不過一個是2011年末，一個是2018年末。一樣是在芯片公司， 不過一個是老牌外企，一個是本土新秀。當時咱們在公司的芯片上作了一個語音通訊解決方案（具體怎麼作的見我前面的文章：如何在嵌入式Linux上開發一個語音通訊解決方案），只有過了中國電信的語音認證客戶纔會用咱們的。老闆把這個任務交給了我，我那時是第一次弄這些，一臉懵逼。既然交給了我，我就盡全力把它作好。認證主要有兩方面內容：音質相關的MOS（Mean Opinion Score，平均主觀意見分）和時延相關的delay。當時MOS的評分標準是PESQ(Perceptual Evaluation of Speech Quality，語音質量的感知評估)，即ITU-T的P.862。通過近幾年的發展，現在變成了POLQA（Perceptual Objective Listening Quality Analysis，感知客觀語音質量評估），即ITU-T的P.863。P.863標準（POLQA）是對P.862標準（PESQ）的升級，適應範圍更廣，評價結果更接近主觀的MOS。通過近三個月的努力，成功過了認證，內心別提多高興了。雖然很累，但技術能力提升了很多，也特別有成就感。此次過的是中國移動（CMCC）手機上的EVS音頻電學認證。關於EVS，我在前面的文章（移動通訊最早進的音頻編解碼器EVS及用好要作的工做）中講過。下面就講講是怎麼過認證的以及怎麼被虐的。

 

前面的文章（Android智能手機上的音頻淺析）講了安卓手機上音頻相關的軟硬件，文章（談談我開發過的幾套語音通訊解決方案）講了在安卓手機上打傳統電話時的方案，知道了通話時主要是CODEC芯片、Audio DSP（ADSP）和CP參與語音數據的傳輸，具體以下圖：

codec芯片主要負責語音的採集和播放，ADSP上主要是編解碼以及語音加強（voice Enhancement，簡稱VE，包括AEC、ANS、AGC等）等，CP上主要是網絡側及空口的處理。CMCC之前對EVS是可選項，但2018年四月份開始變成了必選項，即要入庫的手機必定要支持EVS。咱們公司的手機芯片是支持EVS的，這功能是我和CP的同事共同完成的（我負責Audio DSP上EVS codec相關的，CP同事負責網絡側IMS相關的）。那時中國移動關於EVS認證的case還沒公佈，咱們在實網下對EVS作了基本的調測，能用了。到了七八月份具體case公佈了，全面調測EVS就提上了日程。CP同事、測試同事和我三人組成了一個小分隊，因爲EVS codec在Audio DSP上，這件事就由我來牽頭向前推動。先在實網下作全面的測試，解決了很多語音質量相關的問題（好比噪聲斷續等）。這些問題相對都是較難弄的，花了近一個月。實網下測下來基本感受不到噪聲斷續等問題了，咱們決定開始過移動EVS認證的case。

 

CMCC EVS音頻電學認證的case也主要分兩類：MOS和delay。測試時儀器經過音頻線和手機的耳機孔鏈接進行語音數據的傳輸，儀器經過射頻線和手機上的射頻口相連進行空口數據的傳輸，其框圖以下：

MOS有良好網絡下的上下行MOS、惡劣網絡下的下行MOS、LTE向2/3G切換的切換中和切換後的MOS、數據業務併發時的MOS等。算上行MOS時，儀器把參考音頻經音頻線送給手機，手機上行處理後經射頻線再把碼流送給儀器，儀器解碼碼流獲得PCM再基於POLQA（上面說過如今MOS的評分標準用的是POLQA）跟參考音頻比較獲得MOS分，上圖中的uplink方向給出了示意。算下行MOS時，儀器把參考音頻的碼流經射頻線送給手機，手機下行處理後經音頻線把語音再送給儀器，儀器基於POLQA把收到的語音跟參考音頻比較獲得MOS分，上圖中的downlink方向給出了示意。Delay一樣有良好網路下的delay、惡劣網絡下的delay、LTE向2/3G切換的切換先後的delay、數據業務併發時的delay等，這裏delay是指單向時延（one-way-delay）,即從發端到收端的延時。算delay的框圖以下：

儀器把參考音頻經音頻線送給手機，手機上行處理後經射頻線再把碼流送給儀器，儀器中造成一個loopback(上圖中紅色粗體處)，把這個碼流經射頻線送給手機。手機下行處理後把語音數據經音頻線送給儀器，儀器把收到手機語音數據的時間和參考音頻的發送時間作比較從而獲得delay值。無論是MOS仍是delay都是測屢次（MOS測10次或者20次，delay測50次），而後算平均值做爲最終得分。

 

測試EVS音頻電學的這套儀器很是貴，沒有幾百萬是搞不定的，後面還有每一年向儀器廠商繳的維護費用。大廠通常都會買上一套來調試各類音頻電學指標。上文說過我如今的公司是本土新秀，老闆不是很願意花這麼多錢在這上面。幸虧CMCC有儀器設備免費給相關廠商用，要提早預定，一般一星期批一次，一次兩三個小時。可是通過兩三個星期這樣的運做後發現效率過低（手機校準（校準是爲了找到最好的靈敏度值和gain值，相同的儀器和手機只須要作一次校準，若是有一個變化了就須要從新作校準）一次要花近兩個小時，咱們的手機在實網下打EVS電話沒什麼問題，可是在儀器環境下測時好多case的EVS通話都創建不起來，須要各個領域的同事一塊兒調查，也須要儀器側技術人員的support，可是儀器側的support力度很弱，進展太慢），老闆決定向儀器廠商租設備來調試（租金也是至關昂貴的），即咱們到儀器廠商的實驗室去調試。儀器廠商的實驗室在北京，這樣就有了我和CP同事的北京之行（咱們公司北京有office，測試同事就在北京）。在北京呆了一星期，一樣遇到了很多問題，因爲是在儀器廠商的實驗室，遇到問題時他們支持的力度較大，大部分case都能測起來了，進而也就獲得了相應的MOS分和delay值。良好網絡下的MOS分不只沒有一個達標的，並且有的離達標還很遠，良好網絡下的delay部分達標了。儀器廠商的技術人員安慰咱們說第一次過EVS認證都是這樣的。在過EVS認證這件事上他們見多識廣，咱們就當信覺得真，哈哈。

 

回到公司後咱們簡單總結了一下，並制定了後面的策略：每星期由北京測試同事去儀器廠商實驗室測試一到兩天，一方面驗證前面遇到的問題是否fix，修改後MOS分是否有提升，delay值是否有減少，另外一方面再繼續測未測的case，即採用迭代的方式向前推動。先主攻良好網絡下的MOS分。調查MOS分低（即音質差）主要是把各個處理過程後的語音數據dump出來，再輔以咱們本身開發的各類工具，最終都變成PCM數據用CoolEdit聽，從而得出是哪一個處理過程把音質下降了（主要是噪聲斷續等），而後再在這個處理過程當中找到使音質下降的根本緣由。在前面文章（webRTC中音頻相關的netEQ（一）：概述）中也說過咱們語音通訊中也用到了netEQ，只不過MCU模塊在CP上，DSP模塊在ADSP上。下行CP給ADSP發語音包和netEQ的控制命令，上行ADSP 給CP發語音包和netEQ的反饋信息（主要是上一幀的處理模式和時間戳等）。咱們主要作了四個工具。一是EVS decoder（基於3GPP EVS reference code），把EVS碼流解碼成PCM；二是解析下行dump出來的CP發給ADSP的語音碼流和netEQ控制命令；三是解析上行ADSP發給CP的語音碼流和netEQ反饋信息；四是netEQ DSP模塊的simulator(模擬器)，把下行dump出來的CP發給ADSP的語音碼流和控制命令做爲輸入，netEQ中DSP模塊處理後的PCM做爲輸出，就能徹底覆盤出問題的場景，從而找到根本緣由。在這些工具的輔助下發現了一些問題，也都一一解決了。通過幾個星期的迭代，良好網絡下的MOS分穩步提高，上下行都達到了3.9x，可是不達標（達標是4.0）。討論下來在傳輸環節已經沒有什麼可作的了（依據是用CoolEdit聽儀器中的結果音頻，已經聽不出任何噪聲斷續了），該負責VE的算法同事上場了。剛開始時算法同事也沒什麼招，後來聽測試同事講儀器廠商實驗室有參考機，能夠拿這個參考機測測，若是達標了看儀器上的結果音頻是什麼樣的，好有參考。參考機測下來達標了，上行4.09，下行4.16。把結果音頻發給算法同事，研究頻譜等特性。算法同事嘗試着修改VE裏的參數，前三次以失敗了結，讓人好失望，甚至有點絕望，就差這零點零幾分了！第四次嘗試後總算達標了（上行4.10，下行4.20），好不容易啊！總結下來就是儘可能減小對語音信號的處理，保持原有信號的頻譜等特性。改好後又測了良好網絡下的其餘case的MOS分，全都達標了。後面因爲時間很少了，就開始兵分兩路，一路負責惡劣網絡下的MOS，另一路負責各類場景下的delay。惡劣網絡主要分三個等級（1%丟包10ms jitter/2%丟包20ms jitter/3%丟包40ms jitter），相對OTT語音（好比微信語音，OTT語音常常會出現高於5%的丟包率）不是很惡劣，主要是由於LTE網絡處理語音數據的QoS的級別較高，而OTT語音的QoS級別同其餘數據業務（好比上網）是同樣的，須要作好多補償措施，具體有FEC、重傳等，我在前面的文章（語音通訊中提升音質的方法）對這些措施作過具體介紹，有興趣能夠看一看。提升惡劣網絡下EVS的音質主要是用好丟包補償、平滑等算法。減小delay先是算出各個環節引入了多少delay，而後看是否能減小以及減小多少，主要是減小語音數據緩的時間。例以下行先有鈴聲數據進DMA buffer播放出來，語音數據到來後如放在未播放的鈴聲數據後就會引入delay，這就須要馬上用語音數據去覆蓋DMA buffer中未播放的鈴聲數據從而減小delay。無論是MOS仍是delay，要想達標，就在幾個核心的點上，好比前面講的改VE中的參數就是一個很重要的點，改了後就能提升0.2左右的MOS分。點找到了，達標也就不是很難了，每每是找到一個點並解決了須要很多時間，有時候花了不少時間也不必定能找到，須要很強的專業知識，仍是以修改VE參數的點爲例，須要精通音頻算法的專家。

 

過EVS音頻電學認證前先後後花了四個月左右的時間，遇到了不少問題，參與人數也衆多（咱們建了一個EVS認證的羣，從最初的三四人到最終的近50人，不只有信令處理、媒體處理的，還有硬件的平臺的以及空口的，都是遇到問題涉及到相關人員而拉進羣的），能夠算是一個不小的項目了。我做爲過EVS認證的牽頭者，不只要解決好媒體處理相關的問題，同時還要跟蹤項目的狀態制定計劃等，部分承擔了PM（項目經理）的角色，無論是技術上仍是項目管理上都收穫頗多。