音頻軟件開發同其他軟件開發一樣，都需要去調試。音頻軟件調試同其他軟件調試方法有相同的地方，也有不同的地方，同時調試時還需要藉助一些專門的工具，有了這些方法和工具，就能快速的定位問題和解決問題。下面我們就談談這些方法和工具。
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方法和工具集，對大家都是益處多多。謝謝！
