alsa軟體結構

1,alsa的基本軟體結構    

alsa  app  

--------------------    

alsa lib

 --------------------   

alsa driver  

--------------------   

alsa device driver           

linux下軟體子產品架構的一些重要特點:  

       1),對應用層提供了經過高度抽象的接口,使得可以支援非常多的應用,可以支援現存的許多應用軟體,同時友善應用開發;  

       2),向下支援非常多的裝置驅動,裝置驅動一般隻需要實作子產品定義的一些接口即可,同樣這些裝置驅動相對容易開發; 

以上特點不難在network subsystem/tty subsystem/usb subsystem ...等發現. alsa 同樣保持了這些特點,alsa app調用alsa lib提供的接口, 這些接口的核心内容并不複雜; alsa lib和alsa driver作為整個子產品的中間層,對sound接口做了相當完備的抽象.上面的alsa app隻需要集中注意力到應用邏輯,下層的alsa device driver也隻需要關注如何實作alsa driver 要求的接口.   

2,alsa lib中pcm是如何組織的  

alsa lib pcm部分提供了許多pcm plugin,比如Plugin: hw/Plugin: copy/ Plugin: Route/Plugin: Rate/Plugin: file/...等. 這些plugin的提供大大友善了alsa app的開發. 這些衆多的plugin中,隻有Plugin: hw和alsa driver 打交道,其他Plugin隻需要和Plugin:hw打交道即可.    一般alsa app通路的裝置名稱為 plughw:x,y/hw:x,y/...等類似名稱,這些名稱在alsa lib層一般都會轉化到hw:x,y裝置, 最終轉化為/dev/snd/pcmCxDyc 以及/dev/snd/pcmCxDyc等類似裝置.       

3,alsa driver中pcm是如何組織的

snd module(pcm_native.c)提供了alsa lib需要的接口,這些接口的表現形式 ---标準linux system call.                 

 4,一些結論 

使用者所要開發的軟體子產品一定隻依賴于系統提供的支撐子產品,系統支援子產品隻可以依賴其他系統支撐子產品,絕對不可以依賴于使用者子產品. 這條規則看起來很直覺.   從上面可以看出,使用者子產品的arrow都是指向其他子產品的. 無論是alsa app,還是alsa dev driver.   snd_pcm/snd/snd_timer/snd_page_alloc/snd_ac97_codec/snd_ac97_bus等子產品構成了 alsa driver中間層的主體,對sound接口從邏輯上做了抽象.

ALSA并非是最近才出現的新事物，它實際上已經發展很多年了，不過直到在kernel 2.6，才成為OSS名正言順的替代者。ALSA提供的不隻是幾個聲霸卡的驅動程式，而是從驅動程式到上層應用程式的一整套解決方案。最近花了點時間去閱讀ALSA相關資料和代碼，本文記錄了一些在研究過程中所記的筆記。

  按照ALSA官方網站上的說法，它有如下特點：

1.       有效的支援所有類型的音頻接口，從普通的聲霸卡到專業的音頻裝置。

2.       完全子產品化的聲霸卡驅動程式。

3.       SMP和線程安全的設計。

4.       一個使用者空間的函數庫，提供了高層次的程式設計接口，進而簡化了應用程式的開發。

5.       支援較老的OSS API，相容大多數OSS應用程式。

為什麼說ALSA比OSS更有前途呢？從前有人說ALSA會有更好的性能和更少延遲。但設計良好的OSS驅動程式在性能上并不比ALSA驅動程式差，是以現在大家都不在性能上做比較了，而是說ALSA有下面這些優點：

1.       分離了核心代碼和使用者空間的代碼。隻有必要的代碼才放到核心中，其它代碼在alsalib中實作。

2.       alsa-kernel/alsa-driver的架構設計得更好，不同驅動程式之間可以共享更多代碼。驅動程式的行為也更加統一，對應用程式來說也是有好處的。

3.       alsa-lib提供了更易使用的API,讓應用程式的開發更為簡單

不過OSS似乎也不太服氣，不甘心就這樣讓ALSA搶了風頭。Opensound網站上有一篇《關于音頻的神話與坊間傳說》，寫得非常有煽動性和說服力，可以認為是對ALSA支援者的反駁。我個人也認為ALSA上述的優點完全可以通過改進OSS來達到，而不必推倒重來，或者真正的焦點在于OSS沒有開放源代碼，使得linux愛好者決定自己搞一套。不管怎麼樣，OSS也不會這麼快成為曆史，因為它支援所有的unix系統，而且 ALSA則側重于linux系統。

ALSA由下面幾部分組成：

1.       Driver 核心驅動程式，包括硬體相關的和一些公共代碼。有近30萬行代碼，太龐大的了，隻選擇性的看了core裡一些代碼。比如粗略的浏覽了一遍《Writing an ALSA Driver》，寫得不錯。

2.       Library 使用者空間的函數庫，這是給應用程式使用的。要包含頭檔案asoundlib.h，連結共享庫libasound.so。

3.       Lib-plugins 提供了兩個插件，一個用jack模拟alsa接口，一個用oss來模拟alsa接口。高！alsa可以作為jack的後端，jack也可以作為alsa的後端，alsa可以模拟oss，oss也可以模拟alsa。

4.       Utilities一些基于alsa的指令行小程式，可以作為示例代碼參考。

5.       Tools 一些小工具, 比如vxloader可以用來加載Firmware。

6.       Firmware 一些裝置的Firmware，這些Firmware由核心在适當的時候通過hotplug加載。Firmware其實就是一些程式，每個裝置實際上就是一個獨立的嵌入式系統，聲霸卡也一樣，有自己的程式。但為了節約成本和友善更新，這些裝置可能隻有RAM而沒有ROM，在起動裝置時，由系統（如linux）把裝置的Firmware加載到裝置的RAM裡，裝置才能運作。

7.       OSS Compat 與OSS相容的代碼。

目前ALSA核心提供給使用者空間的接口有：

1.       Information Interface (/proc/asound)

2.       Control Interface (/dev/snd/controlCX)

3.       Mixer Interface (/dev/snd/mixerCXDX)

4.       PCM Interface (/dev/snd/pcmCXDX)

5.       Raw MIDI Interface (/dev/snd/midiCXDX)

6.       Sequencer Interface (/dev/snd/seq)

7.       Timer Interface (/dev/snd/timer)

和OSS類似，也是以檔案的方式提供的，但這些接口是給alsalib使用的，而不是給應用程式使用的。應用程式應該使用alsalib，或者更進階的接口，比如jack提供的接口。

  ALSA程式設計

開發基于ALSA的應用程式時，不要直接使用alsa-driver提供的接口，而應該使用alsalib的函數。alsalib提供了豐富的功能，估計有好幾百個函數，幸好常用的并不多。ALSA的howto提供一個簡單的播放和錄音的示例，值得參考。

  TODO:

繼續閱讀alsa-driver和alsalib的代碼。

研究JACK的架構。