音頻軟件開發中的debug方法和工具

本文系做者原創。如轉載，請註明出處。 謝謝！

音頻軟件開發同其餘軟件開發同樣，都須要去調試。音頻軟件調試同其餘軟件調試方法有相同的地方，也有不一樣的地方，同時調試時還須要藉助一些專門的工具，有了這些方法和工具，就能快速的定位問題和解決問題。下面咱們就談談這些方法和工具。

1，方法

1）log

這是軟件調試中最經常使用的方法，音頻調試也不例外。在寫代碼時加上必定的log, 在出問題時就打開這些log，經過log分析問題出在什麼地方。一個好的log體如今以下幾點：

a)    要有時間和日期，有時候時間戳對分析問題很重要。

b)    函數入口處和出口處要加上log，有了這就能很快看出函數調用流程。

c)    發生問題時的相關變量值要打印出來，這對分析問題相當重要。

d)    log要分級別，常見級別有error/warning/debug/info等。有時候log打印太多會致使load大從而出現不一樣的結果影響分析。

2）二分法

當前版本有問題，而之前的某個版本沒問題，這說明是近期的某個改動引發的。這時咱們就須要用二分法快速找出哪一個版本開始出問題的。先把當前版本和那個好的版本中間一分爲二，取中間那個版本，看有沒有問題，有的話說明這個中間版本以前就有問題了，沒有的話說明是這個中間版本後面的改動引入的。這樣的話就把範圍縮小一半了。在這樣繼續二分下去，直到最後找到最初出問題的版本。找到版本後再看這個版本加入了幾個改動，分析哪一個改動最可能引發這個問題，直到最後找到根本緣由解決問題。

3）crash的分析方法

寫代碼crash是不免的，關鍵是crash後能快速找到緣由並最好後面不犯這個錯誤。一般crash主要有這幾種緣由：空指針，除零，越界，死循環，固然還有其餘的緣由。在Linux下有好的工具，很容易查。有些小衆的OS沒什麼工具查crash問題，若是是作底層的能夠藉助JTAG工具，否則的話還得靠log。Log是實時的還好辦，多加點打印總能找出crash的地方。就怕log非實時，這時只能具體問題具體分析了。記得在一個OS下log非實時，一個模塊相對獨立，只能把函數調用關係和輸入參數值都保存在文件裏，在Linux下作一個應用程序去讀這個保存的文件從而模擬當時的過程，再借助Linux的工具找到crash的地方，最終這個應用程序成了一個工具，之後再遇到相似的問題就能很快解決了。

4）最小系統法

作一個軟件系統時剛開始是一個最小系統，即缺了任何一個模塊，系統不能用。後來加上一個個功能使系統完備。在寫代碼時咱們能夠加上一些標誌位使這些後加的功能enable或者disable。這有助於後面出現問題時排查。下圖是語音通訊的軟件框圖，最小系統是採集播放編解碼網絡發送接收等，沒有這些不能通話。而前處理的一些模塊（AEC/ANS/AGC等）則不是最小系統裏面的，它們是後來一步步加上去的。假設系統出問題了，咱們先disable前處理的諸多模塊，造成最小系統，看有沒有問題，有說明問題在最小系統裏，再繼續調查。沒有的話先把AEC使能看有沒有問題，有說明問題在AEC裏，沒有說明問題在ANS或者AGC裏。如沒有問題繼續使能ANS看是否有問題，有說明問題在ANS裏，沒有說明問題在AGC裏。通過這幾步基本定位問題在哪一個模塊裏，後面再結合其餘方法直到找到根本緣由。

                                      

音頻開發時不論是voice仍是music好多問題是音頻聽下來不對，這時就要用音頻特有的debug方法了。

5）dump音頻數據

Dump音頻數據就是把音頻數據dump出來用工具（好比CoolEdit, 後面講工具時會具體講）播放，或者看波形，或者看頻譜，看是否正確。通常是找幾個可能的dump點，進模塊前一個dump點, 出模塊後一個dump點。若是進模塊前dump出來的數據是好的，而出模塊後的音頻數據是壞的，那麼問題就出在這個模塊了，再一步步排查，最終找到把音頻數據寫壞的地方。仍是以上面的語音通訊軟件框圖爲例，在AEC前設一個dump點，AEC後再設一個dump點，若是AEC前的音頻數據是好的，AEC後的音頻數據很差了，問題確定出在AEC裏。

                                     

Dump音頻數據也有幾種不一樣的方法，在不一樣的場合用不一樣的方法。

a）把音頻數據寫進指定的文件裏，問題復現後把這個文件導出來用工具分析。

b）把音頻數據放進RTP包裏發送到指定的IP地址上，用抓包工具（好比wireshark, 後面講工具時具體講）抓到這些包。因爲是PCM數據，在wireshark上能夠直接聽或者看波形。這多用於語音通訊場景。

c）有時候有些模塊對本身是黑盒的，好比在linux下kernel space的音頻驅動對作use space的來講就是黑盒。在use space裏調查下來音頻數據沒問題，可是最終從揚聲器或者耳機出來的音頻是有問題的，這時能夠用一根音頻線一頭連着出問題的設備的耳機，另外一頭連着電腦，復現問題，用CoolEdit把出問題時的音頻錄下來，先聽確認問題出在這個黑盒模塊裏，而後看波形，是否有規律，若是有規律，好查一些，沒規律再具體問題具體分析。

6）loopback音頻數據

loopback音頻數據就是造成迴環，從而來排查問題。仍是以上面的語音通訊軟件框圖爲例，有幾種不一樣層次的loopback，見下圖：

                                     

1)    把採集和播放造成loopback，即把採集到的音頻數據馬上payback出來，聽下來是好的說明音頻驅動沒問題，很差說明問題在音頻驅動裏面。

2)    把前處理後的數據和播放造成loopback，即把ANS後的PCM數據直接播放出來，聽下來是好的說明前處理沒問題，很差說明問題在前處理裏面。

3)    把編碼和解碼造成loopback，即把編碼後的碼流馬上放進解碼器獲得pcm數據再playback出來，聽下來是好的說明問題出在網絡側，很差說明問題出在編解碼裏面。

經過上面幾個loopback基本上能夠定位問題出在哪一個模塊裏，再在這個模塊裏仔細調查直到找到根本緣由。

 

2，工具

上面講方法時提到了幾個工具，如CoolEdit，下面具體講。

1）CoolEdit / Audition

這應該算是作音頻開發的必備工具了。之前叫CoolEdit，後來被Adobe收購從新包裝後造成了Audition。我我的仍是習慣於用CoolEdit，緣由一是用習慣了，二是CoolEdit能夠保存成PCM文件，而Audition卻不能夠，作音頻開發的保存成PCM文件最方便。

用CoolEdit能夠聽音頻是否正常，也能夠看波形，在出問題時看波形是否有規律，還能夠看頻譜。同時還能夠生成一些特定的音頻文件用於去調試。好比調試音頻算法時用一個時間相對較長的（> 1秒）的音頻文件會很不方便，主要是由於log多，不便於分析。算法一般一幀爲10ms或者20ms，須要幾幀就能夠調試算法了。這時用CoolEdit作一個幾十ms的PCM文件給算法調試用。再好比用CoolEdit作一個20HZ到20000HZ的掃頻文件做爲某個算法或者某個系統的輸入，看這個算法或者系統的頻響如何。

CoolEdit的具體使用能夠看help文件，或者看網上的文章，這裏就不詳細講了。

2）Wireshark

Wireshark主要用於語音通訊場景，抓網絡上的語音包。固然它也能夠抓其餘類型的包，在作音頻開發時就是抓語音相關的RTP/RTCP包了。抓到包後能夠看某個具體包的RTP/RTCP屬性，好比sequence number/time stamp等，從而去分析定位問題等。Wireshark也能夠分析丟包率等，還能夠播放codec 爲g711的語音包，固然還有其餘用途，這裏就不一一說了，有需求的能夠到網上看具體的文章。

3）mediainfo

Mediainfo主要用於音樂場景，用它能夠看到一個音樂文件（例如MP3）的屬性，有采樣率/聲道數/codec類型/碼率等。若是在log中看到的打印值和mediainfo中顯示的值對不上，說明讀取音樂文件屬性的代碼有問題。

4）GoldWave

GoldWave也主要用於音樂場景，用它來作採樣率/codec/碼率等的轉換。支持的採樣率、codec、碼率都特別多，對調試有很多幫助。例如某個系統要支持採樣率爲11025HZ的音樂文件，可是市面上的音樂文件通常爲44.1KHZ或者48KHZ的，這就須要專門的工具去作轉換，從而獲得想要的文件。而後拿這個文件去調試測試看系統是否支持採樣率爲11025HZ的音樂文件。

 

關於音頻debug的方法和工具暫時就先談這麼多，之後想到了被遺忘的以及有新的會及時補充。也歡迎你們補充，造成一個好的debug方法和工具集，對你們都是益處多多。謝謝！