ALSA是Linux 2.6版的語音核心架構。國內工程師有在Linux或Cygwin裡安裝和使用過MPlayer，可是知道ALSA的人卻不多。不過，如果想設計自己公司的語音處理晶片或語音控制卡的驅動程式，那就必須研究ALSA了。因為像MPlayer之類大名鼎鼎的多媒體處理軟體，它們若有被安裝到Linux內，當它們要播音（playback）或錄音時，都必須呼叫ALSA的API，可見得ALSA是多麼重要哩！
ALSA的架構
簡言之，ALSA可以分成三層：語音應用程式或ALSA工具（aplay/arecord）、ALSA程式庫（library）、語音驅動程式（AC97、I2S）。如附圖一所示。
附圖一：ALSA的軟體架構
aplay是播音工具，arecord是錄音工具，兩者的程式碼是相同的，位於alsa官方網站（ALSA官方網站是：http://www.alsa-project.org/main/index.php/Main_Page）alsa-utils目錄中。它們是在文字模式（text mode）內執行的執行檔，沒有使用者圖形介面（GUI）。若想要在嵌入式Linux內使用GUI播音軟體，可以選擇Xine或Audacity來移植；若想使用Linux GUI錄音軟體，可以考慮選擇Audacity或SoundRecEd來移植。
移植的門檻
雖說Linux的ALSA語音軟體程式都可以從網際網路中免費下載獲得，不過，要想將Linux GUI播音或錄音軟體移植到嵌入式Linux內，還必須在X視窗中同時移植GTK+或OpenGL之類的相關程式庫（library）。當然在這之前，你必須已經將X視窗（X11）成功地移植到嵌入式系統內。由於嵌入式系統使用的CPU等級不同，所以，必須在桌上型電腦內利用cross-compiler來編譯這些程式碼，但只要有一個軟體元件編譯不過，就甭想將它們安裝到X視窗中。雖然，可以利用Google來查詢他人的解答，可是因為程式版本不同、CPU不同、編譯工具不同，你必須不斷嘗試錯誤，最後如果運氣好的話，才能安裝成功。這過程有時是很漫長的折磨，很多人到最後都放棄了。這是在安裝X視窗或任何Linux GUI軟體時，都會遇到的痛苦挑戰。如果你老闆不懂，以為可以像在微軟視窗或WinCE中輕鬆地安裝GUI軟體，那你鐵定會被他限定的時間壓的喘不過氣來！這是移植的門檻之一。
alsa-lib是ALSA專屬的程式庫，它是一種類似plug-in的程式庫。ALSA官方網站有它詳細的API說明。簡單說，alsa-lib也是應用程式，它不屬於Linux核心程式，因此，使用者必須自己下載、編譯和移植它。一般而言，編譯和移植alsa-lib並不困難，因為它和aplay、arecord一樣，都不是GUI軟體。也不需要刻意修改它，因為它被ALSA官方持續維護著，程式若有錯誤，早就被人改好了。錄音時常會發生overrun問題，播音時則可能會出現underrun問題，發生這類問題的原因大半是源自於alsa-lib，但不是因為alsa-lib有bug，而是因為編譯出來的alsa-lib有錯誤，才導致這類問題的發生。但為何會編譯錯誤呢？
可能是刻意修改alsa-lib原始程式後造成的。但為何要刻意修改alsa-lib原始程式？很可能是因為發現了overrun或underrun，直覺認為是alsa-lib的錯誤。此時，軟體工程師往往會很天真地去修改alsa-lib，但大多數會越改越糟糕。明明沒錯，還去亂猜、亂改，此時，軟體工程師就像一頭迷路的羔羊一樣可憐。他們萬萬沒想到CPU或硬體處理速度不夠快也會造成這類問題。或者他們已經跟老闆報告了，可是老闆不相信CPU或硬體的速度不夠快，硬是責怪軟體工程師的程式有問題。由此可見，老闆的判斷力是多麼重要啊！
要知道，ALSA是設計給Linux系統使用的----一般而言，是指x86桌上型電腦----並不是專給嵌入式Linux使用的。所以，使用alsa-lib後CPU會有額外的負擔，如果嵌入式系統的CPU不夠快，不發生overrun或underrun才怪！此外，連裝在桌上型電腦內的Skype在運行時，都會發生語音延遲（delay），嵌入式Linux系統在使用alsa-lib後，偶而也會發生這種延遲。任何作業系統都不是「萬靈丹」，Linux也一樣。何況Linux的很多軟體都屬於新科技或「bleeding edge」或「cutting-edge」，使用Linux前必須先有這種認知才是。
語音驅動程式是隨著硬體（SoC和語音DSP）的不同而不同的，所以需要修改，之後才能移植。它也是移植的門檻之一。如果遇到無法播音或錄音，八成是這個驅動程式有bug造成的。CPU不管是ARM或MIPS或其它，有幾個地方是必須注意或修改的：1.硬體支援的音訊格式（format），例如，S16_LE、S8_LE……等；2.取樣速度；3.語音解碼器的FIFO大小；4.buffer和period大小；5.trigger時，DMA繼續傳送資料的方法；6.如何讀取目前的正確位置；7.如何處理最後一筆資料，才不會出現明顯的中斷聲。此外，有些小公司設計的SoC本身雖然有支援AC97或I2S介面，可以外接不同廠牌的語音解碼器，但是卻無法同時支援單音或立體音的播放或錄音，縱使在這些SoC的規格書中聲稱可以。
ALSA的架構
簡言之，ALSA可以分成三層：語音應用程式或ALSA工具（aplay/arecord）、ALSA程式庫（library）、語音驅動程式（AC97、I2S）。如附圖一所示。
附圖一：ALSA的軟體架構
aplay是播音工具，arecord是錄音工具，兩者的程式碼是相同的，位於alsa官方網站（ALSA官方網站是：http://www.alsa-project.org/main/index.php/Main_Page）alsa-utils目錄中。它們是在文字模式（text mode）內執行的執行檔，沒有使用者圖形介面（GUI）。若想要在嵌入式Linux內使用GUI播音軟體，可以選擇Xine或Audacity來移植；若想使用Linux GUI錄音軟體，可以考慮選擇Audacity或SoundRecEd來移植。
移植的門檻
雖說Linux的ALSA語音軟體程式都可以從網際網路中免費下載獲得，不過，要想將Linux GUI播音或錄音軟體移植到嵌入式Linux內，還必須在X視窗中同時移植GTK+或OpenGL之類的相關程式庫（library）。當然在這之前，你必須已經將X視窗（X11）成功地移植到嵌入式系統內。由於嵌入式系統使用的CPU等級不同，所以，必須在桌上型電腦內利用cross-compiler來編譯這些程式碼，但只要有一個軟體元件編譯不過，就甭想將它們安裝到X視窗中。雖然，可以利用Google來查詢他人的解答，可是因為程式版本不同、CPU不同、編譯工具不同，你必須不斷嘗試錯誤，最後如果運氣好的話，才能安裝成功。這過程有時是很漫長的折磨，很多人到最後都放棄了。這是在安裝X視窗或任何Linux GUI軟體時，都會遇到的痛苦挑戰。如果你老闆不懂，以為可以像在微軟視窗或WinCE中輕鬆地安裝GUI軟體，那你鐵定會被他限定的時間壓的喘不過氣來！這是移植的門檻之一。
alsa-lib是ALSA專屬的程式庫，它是一種類似plug-in的程式庫。ALSA官方網站有它詳細的API說明。簡單說，alsa-lib也是應用程式，它不屬於Linux核心程式，因此，使用者必須自己下載、編譯和移植它。一般而言，編譯和移植alsa-lib並不困難，因為它和aplay、arecord一樣，都不是GUI軟體。也不需要刻意修改它，因為它被ALSA官方持續維護著，程式若有錯誤，早就被人改好了。錄音時常會發生overrun問題，播音時則可能會出現underrun問題，發生這類問題的原因大半是源自於alsa-lib，但不是因為alsa-lib有bug，而是因為編譯出來的alsa-lib有錯誤，才導致這類問題的發生。但為何會編譯錯誤呢？
可能是刻意修改alsa-lib原始程式後造成的。但為何要刻意修改alsa-lib原始程式？很可能是因為發現了overrun或underrun，直覺認為是alsa-lib的錯誤。此時，軟體工程師往往會很天真地去修改alsa-lib，但大多數會越改越糟糕。明明沒錯，還去亂猜、亂改，此時，軟體工程師就像一頭迷路的羔羊一樣可憐。他們萬萬沒想到CPU或硬體處理速度不夠快也會造成這類問題。或者他們已經跟老闆報告了，可是老闆不相信CPU或硬體的速度不夠快，硬是責怪軟體工程師的程式有問題。由此可見，老闆的判斷力是多麼重要啊！
要知道，ALSA是設計給Linux系統使用的----一般而言，是指x86桌上型電腦----並不是專給嵌入式Linux使用的。所以，使用alsa-lib後CPU會有額外的負擔，如果嵌入式系統的CPU不夠快，不發生overrun或underrun才怪！此外，連裝在桌上型電腦內的Skype在運行時，都會發生語音延遲（delay），嵌入式Linux系統在使用alsa-lib後，偶而也會發生這種延遲。任何作業系統都不是「萬靈丹」，Linux也一樣。何況Linux的很多軟體都屬於新科技或「bleeding edge」或「cutting-edge」，使用Linux前必須先有這種認知才是。
語音驅動程式是隨著硬體（SoC和語音DSP）的不同而不同的，所以需要修改，之後才能移植。它也是移植的門檻之一。如果遇到無法播音或錄音，八成是這個驅動程式有bug造成的。CPU不管是ARM或MIPS或其它，有幾個地方是必須注意或修改的：1.硬體支援的音訊格式（format），例如，S16_LE、S8_LE……等；2.取樣速度；3.語音解碼器的FIFO大小；4.buffer和period大小；5.trigger時，DMA繼續傳送資料的方法；6.如何讀取目前的正確位置；7.如何處理最後一筆資料，才不會出現明顯的中斷聲。此外，有些小公司設計的SoC本身雖然有支援AC97或I2S介面，可以外接不同廠牌的語音解碼器，但是卻無法同時支援單音或立體音的播放或錄音，縱使在這些SoC的規格書中聲稱可以。
