Android音頻系統的改進設想和展望[續] 底層驅動的問題和改造
nbx 于 2012.03.20 18:53:37 | 源自:www.soomal.com | 版權:投稿 | 平均/總評分:09.33/168

本文系網友nbx 投稿,轉載請征得作者同意

  • 注:本文僅代表網友個人看法,不代表Soomal觀點。

    上篇文章《Android音頻系統的改進設想和展望 PulseAudio介紹》[作者:nbx ] 反響不少,不過由于寫得太匆忙,沒有認真去分析Linux和Android相關的資料,問題也是一大堆。其中,最嚴重的問題就是我實在太高估Google了,認為現在Android的ALSA驅動是沒問題的。可那并不能完全解釋AudioFlinger為什么還要繼承原來ALSA的問題。做大量的預處理和SRC,這些事情完全可以通過ALSA驅動層來調用硬體完成,而不是寫一堆垃圾代碼去實現劣質SRC和延遲高達350ms的“高速緩存”(APP的開發便利性不是理由,因為Google完全可以把AudioFlinger寫得更簡單)。

    所以,答案就是:Google并沒有解決ALSA的問題。Android和ALSA和Linux的ALSA是兩回事。

  • 我曾提到ALSA原來并不完善,其中之一就是早期的ALSA API連SRC都無法實現,要播放非匹配采樣率的音頻只能通過切換采樣率和通過PulseAudio等中間層API來解決。而Android內置的ALSA是早期的ALSA版本精簡而來,說好聽點就是Google修改的版本,實際上就是Google自己移植并去掉ALSA大量API甚至驅動層功能的閹割版本。閹割的目的是為了減少或者說去掉GPL授權的影響,加重Google在Android源代碼控制上的話語權,也能說服不愿意將自己驅動或者修改代碼開源的廠商加入到Android的開發上(雖然Android也支援HAL層的私有驅動,但是……現在幾乎所有的音頻Codec驅動是基于ALSA的)。雖然Google樂于聽到“Android和ALSA和Linux的ALSA是兩回事”的說法,并將其內部命名為“TinyALSA”(精簡版ALSA)。一般來說,在維持功能的基礎上精簡代碼是好事,可Google對于ALSA的精簡,完全可以做為失敗案例看待。如果說AudioFlinger是Android音頻系統的噩夢,那么,TinyALSA則是Android音頻系統的災難。

    ALSA同時掌管著Android/Linux的音頻硬體驅動和底層API,因此,ALSA對于codec的性能和功能則起著決定性的作用。Google在大量刪除ALSA代碼的同時,并沒有將失去的功能補回來。PulseAudio相對于AudioFlinger的優勢就是加強底層驅動的作用,但是Android的TinyALSA則是啥功能都缺:

    • 1、不具備重采樣功能(這個待考量,畢竟硬體支援的)
      2、不具備緩存功能
      3、無法切換采樣率,采樣率只能在編譯驅動時固定
      4、不具備影音相關的重要功能(雙聲道/多聲道切換,AC3 Fliter,AC3解碼等等,模擬輸出只能靠AudioFlinger轉換簡單實現,高級實現則需要數字輸出到獨立的硬體解碼器。)

    消費者們應該慶幸GoogleTV的艱難前進,否則他們能看到的高清影像也是僅限于視訊的層面上。

  • 所以,底層驅動重寫才是Android音頻系統改造首要的任務。底層的改造可以說很簡單,也可以說很困難,ALSA就有一個叫SALSA(Small ALSA Library)的精簡版本,但是驅動層和API的重要功能都還在,要實現低延遲,硬體采樣切換和硬體SRC,就必須在驅動中實現。所以,PulseAudio想在Android上使用,首先是要在系統上安裝功能和性能都相對完整的ALSA,或者使用更好的底層驅動(如OSS或者非開源的HAL廠商驅動)。

    SALSA要在Android上使用并不難,難的不是技術問題,而是接近于政治的授權問題。Google并不樂意在Android里使用GPL授權的代碼,去GPL化是Android最大的政治任務,而PulseAudio、SALSA等代碼均是以GPL或者LGPL授權的。實際上,這體現了Google和廠商們的極大矛盾:一方面他們依賴于整個GPL開源體系才能得到Android今天的成就,另一方面他們又想將這個成果占為己有。而實際上除了底層晶片驅動開發商,Google等企業相對于開源社區對Android,實在是九牛一毛,自己的私有代碼效果還適得其反。Google自己折騰出來的AudioFlinger和TinyAlsa就是很好的例子。但就算如此,享受著開源帶來的成就,Google也無法容忍GPL代碼進入Android源里面,一個是因為法律問題,另一個這是為了保護廠商的利益。就算PulseAudio和SAlsa組合能達到較好的效果,也能保證兼容性的前提下,也無法進入正規的Android體系。

  • 現在,有廠商號稱解決了Android的SRC問題還申請了專利,個人估計也只是將AudioFlinger重寫,讓其忽略SRC處理,并不能說沒有了AudioFlinger的SRC,音質就能有所改善。而且,作為廠商自主的改進,謀求利益的目標也不會讓其將修改提交至Android主代碼庫或者分享。廠商修改了代碼,卻在自己的產品上用了音質不佳的處理器,那根本問題還是無法解決。而某個堆料的Android隨身聽號稱自帶播放器直接使用底層驅動。但是,TinyALSA底層驅動功能有限,而應用層依然是AudioFlinger在掌控系統,問題也無法解決。如果不能正常播放高清音頻,那么,采用的DAC晶片就算有32bi192KHz的解碼能力,它還是會SRC到44KHz來播放,這是極大的浪費。

    Android要改善音質,到底該怎么辦?

    • 對于開源社區和智能裝置開發商來說,可以借助自己的開發能力或者第三方的API和驅動,繞過Android的API,從而改善延遲和SRC問題,但是不要指望能被Google接受。
      對于硬體廠商,他們首先要保證晶片的數字音頻不能有差錯,codec或者DAC要運用合理,電路設計也不能出現低級失誤。
      而對于Google來說,必須把現在的垃圾代碼全部砍掉,重來。這是最徹底,也是最好的辦法。
      但是,現在的Google完全不具備這樣的開發能力。高品質音頻應用,離Android還很遙遠,離Google更遙遠。
    請評分
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    058.023.***.***
    058.023.***.***
    73
    058.023.***.***
    058.023.***.***
    72
    058.023.***.***
    058.023.***.***
    71
    058.023.***.***
    058.023.***.***
    70
    014.144.185.***
    014.144.185.***
    發表于2013.05.03 17:34:47
    69
    202.149.***.***
    202.149.***.***
    讀了樓主的文章后有強烈的同感!其實最早Android的Audio系統設計只停留在有聲音出來,省電就行!至于音質,延時(這個也是論壇上抱怨最多的)等完全不考慮。現在到4.1了才慢慢想起考量這些因素!不過基本架構還是如此有些東西很難改。其實SRC的問題還是比較好解決的,不知為何很多廠商的還是有48->44->48這樣的問題。
    發表于2012.09.25 10:19:41
    68
    061.093.***.***
    061.093.***.***
    Very Good Because I Dont Operation
    發表于2012.08.18 10:20:55
    67
    183.034.030.***
    183.034.030.***
    發表于2012.06.12 23:13:08
    66
    10
    因為你不在乎,所以我沒必要做好,這不是做精品的邏輯
    發表于2012.04.15 15:34:21
    64
    059.175.***.***
    059.175.***.***
    以手機為例,絕大部分情況音頻應用是獨占模式的。在手機上視訊播放器和音樂播放器是不會同時播放的,也不會在通話的時候而播放器還同時響著……

    偶爾才會有不同采樣頻率的音頻同時發聲的情況。例如聽看視訊(通常是48KHz的音軌)時后臺某個IM軟體的提示音(通常采樣頻率是22.05KHz)響了,這時SRC是不可避免的。

    因此我認為移動作業系統首先需要能輸入、輸出不用采樣頻率、精度的音頻,其次還應根據實際情況合理進行SRC。

    例如播放44.1KHz的音樂時,提示音響了,即使提示音的采樣頻率是48KHz,也應該SRC至44.1KHz。而播放視訊中48KHz的音軌時,提示音響了,即使提示音的采樣頻率是44.1KHz,也應該SRC至48KHz。換句話說,應該以前臺應用的采樣頻率為基準。

    ——詳細閱讀
    發表于2012.04.15 14:51:11
    63
    事實是, 對于大多數人, 只要夠響, 特別是低音夠響, 就叫好

    我再重申一次, 看看Beats能忽悠多少人, 你就能明白以Google的立場這根本就不是問題

    舉個我身邊的例子, 我在公司用K702, 同事都表示聽起來跟30元的飛利浦頭戴沒有區別
    發表于2012.04.07 16:33:08
    62
    182.148.187.***
    182.148.187.***
    發表于2012.04.01 12:30:43
    60
    難解決的問題通常難在成因無法定位, 但這個問題其實原因都是明擺著的, 要解決是非常容易的, 樓主這些看似專業的分析, 反而顯示樓主對軟體開發一無所知.

    但是, 對Google來說, 這是根本不需要解決的問題, 你就看看HTC的Beats能忽悠多少人吧...
    發表于2012.03.30 17:20:51
    59
    03
    android,還有高通的問題,都有人在關注。即便是有一小部分人特別敏感,但對于行業對于一個系統來說,鞭策修改、完善,也是有必要的
    發表于2012.03.27 19:25:23
    58
    03
    且別談論這么專業的東西。就Android音質來說,有幾個普通消費者能聽出這些門道來?蘋果音質那么牛B,那么有幾個人能把這種優勢發揚光大?
    發表于2012.03.27 19:22:19
    57
    03
    http://www.soomal.com/doc/10100002733.htm
    發表于2012.03.27 19:03:36
    56
    219.133.***.***
    219.133.***.***
    據說4.0已經解決了SRC的問題,是否如此呢?
    發表于2012.03.27 18:57:35
    55
    03
    發表于2012.03.22 18:57:54
    54
    提示
    本貼不可匿名回復,回復等級為:1 ,您現在正處在潛水狀態
    回復
    驗證碼
    0467 為防止廣告機貼垃圾,不得已而為之
    表情
    正文
    京ICP備11010137號 京ICP證110276號 京公網安備110114000469號