Android2.2、Android2.3 、Android4.0 audio hardware子產品分析

 Android2.2、Android2.3 、Android4.0 audio hardware子產品分析

      從事Linux開發的工程技術人員都知道，ALSA是Advanced Linux Sound Architecture的簡寫，它現在很流行，起初使用在台式電腦上，随着嵌入式的發展，它有把觸角伸入了新的園地，并且在這個新舞台上越來越受歡迎。ALSA很強大，功能很豐富，當然本身就比較龐大了一些。事情都是這樣的，使用起來簡單，就必然有個環節要付出艱辛, ALSA就幹了這樣一件事。在android2.2上，Google将其視為掌上明珠、座上賓，将其加入了maintree，是以在android2.2上，在hardware層，大多公司選擇了ALSA作為跟driver打交道的幫手，當然也有高通這些公司，一直堅持自己私有的一套東西。當然android還是蠻開放的，允許你自己來選擇、實作！在2.2上編譯出來的共享庫為alsa.XXX.so,xxx可以為産品名稱，也可以使用default，随即就是alsa.default.so。

   到了android2.3，變化了，ALSA被幹掉了！！！可悲啊！Google居然寫了自己的一套迷你接口！開源的ALSA雖然有很多東西你用不上，但是自己寫一套迷你這樣的接口也變成私有的了，不利于以後的發展，有一種憂慮是Google自己寫的這一套東西能不能跟ALSA的release同步更新，能不能跟上這個腳本，這并非沒有道理。如果使用Google寫的迷你接口，就會出現driver還是使用ALSA的，user space使用Google的，感覺就是核是别人的，殼是自己的，這樣工作是能工作，搭不搭啊？driver裡出錯了的情況下，Google的接口怎麼辦？沒看見how

to process，隻是give up audio data。2.3裡面對audio的操作，打開裝置、關閉裝置，非常頻繁，不覺得很好。

   筆者通過比較2.3的audiofliger跟2.2的audiofliger後，分析後認為，2.3可以把2.2使用ALSA的hardware layer的code完全merge到2.3來工作，因為在audiofliger中，調用hal layer的接口沒有發生變化，也算Google留了一手吧！

   到了最新的android4.0，Google整出來了一個tinyalsa，還稍微公道一點，還是沾上了alsa這幾個字，隻不過是tiny的。但是筆者分析了4.0的audiofliger後發現，audiofliger調用hal layer的接口發生了翻天覆地的變化，猛啊！4.0把play跟capture分得更開放了，自己管自己的，audiofliger都從原來3k來行，擴張到了5k多行，大動幹戈啊！苦了的還是coder啊！從接口上來看，開放性更高了！當然hal layer需要大變樣了！不過還是可以使用ALSA接口來實作。不管是ALSA，還是tinyalsa，歸根結底是跟driver打交道的最後一關，跟hal

layer的控制邏輯什麼的關系不大，看到Samsung的參考代碼就是使用了自己的一套實作。

    下面筆者就來分析下android4.0的audiofliger如何調用hal layer功能代碼的：

調用關系解析：

AudioFliger.cpp

  分析清楚了這種關系，我們隻要去完善hal layer的代碼即可，選哪種方式實作，是你的自由！就以後代碼的移植性、相容性來說，我還是覺得ALSA更好一些，學習的資料也更多，碰到了一些問題，還能Google出來幫忙，用私有的，能實作，麻煩還是會有的！

  一家之言，僅供參考！