漫談Linux下的音頻問題(轉)

標籤：http   io   os   使用   ar   for   strong   檔案   資料   

轉自 http://www.kunli.info/2009/03/24/linux-sound-issue/

現今的互連網，比較Linux和Windows的戰爭貼基本都成月經貼了。一群群激進的使用者不斷轟轟烈烈攻擊對方，但是很少有能拿出新鮮乾貨的，基本上雙方理由我現在都能背得了。在攻擊Linux的陣營中，一條很重要的理由就是：硬體驅動不完善。

今天要談的音效卡問題，就是屬於“驅動”這類問題。我在我工作用筆記本，家用筆記本，工作用伺服器兩台，上面都裝過Ubuntu，無一例外遇到聲音的 問題。去ubuntu.org看看，抱怨音效卡問題的呐喊不絕於耳，無論是菜鳥，中鳥還是老鳥。當然不光是ubuntu，debian系的，Redhat系 的（包括Fedora），據我所知都能找到類似的問題。我的部落格之前也有關於聲音問題的文章。到底是什麼原因導致Linux這麼難發聲呢？

Ubuntu官方Forum上有一篇非常好的文章談了這一點。本文其實是該帖原意的中文表達。但這隻是從理論的高度上來分析的，如果你是遇到問題了，通過搜尋引擎來到了這裡，請直接看本文“總結部分”，這部分的reference post基本上就就是Ubuntu 音頻問題大全了。

現在讓我們從下到上對這個問題來一次bottom-up的分析吧。

首先，Linux社區面對的最大也是最現實的現狀，就是得到的支援太少了。從晶片的層次講，每一個OEM商都有能力去配置線路的串連，以適應自己生產機器的需求，比如一個廠商可以在機器上搞兩個麥克風介面，一個在前面板，一個在後面板；而另一個廠商則可能會反過來配置，諸如此類。商家們搞完個人化，弄好Windows驅動，就萬事大吉開慶功會了，可憐我們的Linux社區不得不針對不同機器的不同配置進行處理，然後還要保證使用者們能搞清楚自己的機器是什麼樣的配置情況。

從音效卡本身的層次講。目前，台式機最流行的也就是創新的音效卡了。最讓人沮喪的就是，創新的Linux驅動從來就沒有做好過。創新自己也沒有辦法，乾脆自己就放棄了這塊的開發，於去年11月宣布公開發布Sound Blaster X-Fi和X-Fi Titanium系列的Linux 32/64-bit驅動原始碼，說好聽點，叫做眾人拾材火焰高，說不好聽點，就是爺不玩了，誰愛用誰開發去。當然也有一些支援比較好的，比如C-Media的一些板載，或者就是那種高端和專業的音效卡了。

是不是覺得很沮喪？Linux的問題就在這裡，如果你哪天發現x廠商發布一款超級無敵牛逼限量發行1000套的硬體，然後你想入手給周邊眾多狐朋狗友炫耀，然後很不幸你用的是Linux…….好吧，你必須祈禱在另外購買的999個人裡面有至少2-3個Linux開發人員，注意，不是所謂的高手。然後再把硬體晾在家裡幾個月，等待驅動的推出…….

為什麼Linux的驅動就這麼難開發呢？有人會說，驅動不就是一個翻譯轉換組件麼，你音效卡晶片不就是通過作業系統提供的底層服務和其他軟體打交道的麼，Linux源碼都在那裡了，這麼多底層硬體驅動樣本都在那裡了，你怎麼就開發不出來呢？

對，驅動的作用就是講作業系統傳遞過來的命令和請求翻譯並遞交給音效卡晶片，並將結果反饋。正因為這樣，驅動就必須對硬體的細節非常瞭解。它必須知道，並能檢測，那些廠商對晶片的韌體或者配置電路做了什麼手腳，因為OEM們從來就懶得去發布這種資訊。否則，就算是同樣的晶片，也無法保證能適應不同的cable搭配。這個難度有多大呢？舉個例子，就算是在同樣的電腦的同樣的晶片集上，新的7.1環繞音效卡晶片的麥克風輸入的線路，也可能是和以前老的5.1的配置過的音效卡晶片的speaker輸出用的是相同的線路。

現在，你知道問題所在了吧？作為驅動編寫者，他們可以讓驅動去適應所能發現的所有的變化，但是，這就像一場猜謎遊戲一樣，沒有盡頭。所以，如果你擁有一款比較特殊的音效卡晶片並受困於其Linux驅動，請不要責備編寫驅動的人，他們已經春蠶到死絲方盡了。如今，最有名且活躍的Ubuntu/linux驅動編寫團隊要數ALSA和OSS了，對於他們所接受的這種極度困難的任務，我們所能作的，應該是對他們的感謝。

講完驅動，來講講音頻伺服器吧。音頻伺服器就是位於驅動上面一層的東西，它負責給那些需要音頻支援的應用提供核心服務，同時還調度這些服務，以及作為其他硬體和軟體互動的介面抽象。總的來說，音頻伺服器就是用來串連應用程式到你的音效卡，或者到網路，或者哪都不到，如果你配置錯誤的話。

剛才提到的ALSA和OSS團隊，不僅僅提供驅動，同時還提供音頻伺服器的服務。對於ALSA來說，大多數提供的服務是單獨啟動並執行程式，比如ESD，Enlightened Sound Demon，這玩意允許多個應用程式共用音頻服務。這些程式已經開發了好幾年了，但是都是以一種比較混亂的方式去解決已經觀察到的缺陷。而OSS呢，則是一個更老的項目，它是核心版本2.4.x時期的唯一認定音頻系統，但之後一度被ALSA所替代，最後還是存活了下來。關於兩者的比較，請參考這裡，我就不贅言了。後來OSS整個被重寫，被命名為OSS4，現在還在活躍中。

接下來要介紹的Pulseaudio則是一個比較新的，完全獨立的音頻伺服器，只不過它利用的是ALSA的驅動，所以其目標就是替代ALSA的音頻伺服器，包括所有的輔助部分，比如ESD。Pulseaudio同時還致力於提供ALSA當初很難提供的功能，比如網路廣播，同步重新整理多個音效卡，分別控制不同應用程式的音量，以及很多別的好玩的功能。也有小道訊息指出，Pulseaudio正在實驗看能否工作在OSS4.1基礎上。

然後我們看看Jackd。很多人都把Jackd看作是音頻伺服器，這其實是不準確的，它不是音頻伺服器，它的本質是音頻串連套件。它的設計目標就是圍繞著提供某些應用所需要的服務來制定的。什麼樣的應用呢？是那些為音樂界專業大佬們服務的，這些應用的特殊之處在於，他們需要“即時”。比如說，它們可能是位於支援即時核心/CPU優先訪問和底層驅動訪問的作業系統，用於減少在一些對時間狠敏感的活動中可能會出現的延遲或者中斷，比如現場錄製啊，表演啊之類的。Jackd支援所有以JACK API套件編寫的應用程式串連在一起，並同時被鍵盤或者midi裝置本地或遠程操作。所以說，Jackd非常適用於音樂家。但正是由於Jackd提供了如此底層的控制，所以需要很仔細地去支配資源，並可能和同樣希望支配這些資源的音頻伺服器相衝突。考慮到這點，無論是ALSA OSS還是Pulseaudio音頻伺服器，都提供了專門的模組負責和Jackd互動。

還有一個值得一提的玩意就是Phonon，這是一個新的音頻伺服器和應用API，專門用於KDE的，它可以相容Pulseaudio以及ALSA驅動。具體的介紹請參加這篇文章。

講完了音頻伺服器，接下來講講介面。和驅動不一樣的是，音頻伺服器需要一個公用介面，使用者才能和它們互動，並告知自己的需求。這個介面在哪裡呢？就在菜單裡面的System/Preferences/Sound裡面，開啟看看。在這裡，你可以指定將系統的聲音送往音頻伺服器，或者直接送往驅動。前者將導致音頻伺服器掌控一切，後者則會以驅動為主，伺服器為輔。如果你選擇autodetect，那第一個應用程式如何決定聲音傳輸路徑，之後的應用程式就會遵循這個路徑。如果你選擇音頻伺服器，那麼伺服器會幫你管理，你可以在其之上做出一些調整。像ALSA就可以調用ESD來做聲音共用，Pulseaudio則會自己搞定這個。你還可以讓一個音頻伺服器來調用另一個，比如讓Pulseaudio作為ALSA的預設音效卡，這樣所有的ALSA相關程式都會被重新導向到Pulseaudio，這個過程，應用程式都是不知道的。

對於ALSA來講，它的介面包括了很多調音工具，最基本的就是在終端中調用的alsamixer，當然，你也可以用GUI版本的alsamixer。在調音工具中，你可以通過各種各樣的滑塊和開關來控制音效卡，當然有什麼樣的滑塊和開關取決於你音效卡的類型了。當然還有我們更熟悉的音量控制器，在這裡也可以調節很多的選項。ALSA另一個經常使用的介面就是asoundrc檔案，你可以通過手工編輯它，也可以用asoundconf-gtk來調整選項。

對於Pulseaudio來說，它本身對於驅動並沒有很深入的控制，所以Pulseaudio也是調用的ALSA的調音工具。然後，Pulseaudio可以控制主音量，聲道的音量，應用程式的音量，等等。Pulseaudio的介面給使用者提供了很詳細的控制選項，在Pulseaudio音量控制，也就是pavucontrol中，你可以看到你所有的輸入輸出裝置，並可以將其中任何一個設定成預設裝置。你還可以在不影響應用程式操作的前提下控制任何程式的音量，以及它所使用的裝置。在Pulse Audio Preferences (paprefs)中，你可以控制對你音訊裝置的網路訪問，建立RTP伺服器，甚至建立實際上幾乎等同於實際硬體裝置的虛擬設備。

正是由於這麼多不同的音頻格式，不同的音頻伺服器，為了保證音頻仍然能正常工作，我們最後不得不被帶進一個充斥著音頻濾波器，外掛程式，封裝器（wrapper）等等組件的時代。為了能讓大家理解這些東西是怎麼工作的，舉大名鼎鼎的Amarok作為例子吧。

當你準備使用Amarok播放mp3的時候，Amarok會先看看你指定的檔案，然後對自己說，好，現在我需要一些協助，讓我來看看誰能協助我……好，xine引擎，你小子有mp3外掛程式，來把mp3檔案轉換成我能使用的東西，就是你了。Xine一看，喲，Amarok需要幫忙了，哪能見死不救呢，立馬將mp3外掛程式雙手奉上。Amarok會再對xine說，來，能幫我把資料送到Pulseaudio音頻伺服器那裡去嗎？Xine自然不敢怠慢，立馬找到Pulseaudio，說，哥們，我這裡有Amarok送過來的流資料，你能幫忙播放一下嗎？Pulseaudio說，沒問題，拿過來吧。於是Amarok得到訊息，開始處理檔案，送到xine，xine將其轉換為pcm，並將pcm流送到Pulseaudio，Pulseaudio將流資料送到alsa負責驅動的輸出音訊裝置。如果這個裝置是音箱或者耳機，pcm就會在alsa音量控制中被調整以讓你能聽到。所以最後整個流程是這樣的

Amarok-xine-pulseaudio-alsa driver-sound card-speakers

只有xine能做這種後端處理的服務嗎？不是，另一個大名遠揚的服務就叫Gstreamer，喜歡用Rhythmbox的朋友估計不會對其陌生。事實上Gstreamer和xine還能提供視頻處理服務，只要有相應外掛程式和濾波器支援就行了。這種方式對於程式開發人員來說更加具有吸引力，原因就是他們只需要編寫和Gstreamer或者xine互動的介面，其他細節一律不關心。Gstreamer和xine同時也提供可以更改的設定檔。

對於外掛程式來說，程式開發人員可以建立自己的外掛程式，實際上，無論是gstreamer還是xine，還是alsa或者 oss 或者pulseaudio或者jack，都是很常見的程式外掛程式。音頻伺服器也是包含了各種各樣外掛程式的，比如Pulseaudio就有很多被稱為模組的外掛程式。ALSA也有很多封裝到libasound2和libasound2-plugins的外掛程式。外掛程式是一個很好的東西，使用者應該去儘可能多地擁有他們，這樣才會有更好的靈活性，以及更寬的選擇。

總結：
基本上，這就是音頻系統在系統中工作的基礎知識。希望看到這裡的朋友沒有被搞昏頭了。這篇文章只是給大家一個基礎概念，並沒有牽涉到很多的細節。關於具體很多問題是怎麼產生的，怎麼解決，可以參考一下一些資料

漫談Linux下的音頻問題(轉)