科普貼關于Android的音頻SRC處理,音質(zhì)問題

希范 · 發(fā)表于 2014-2-25 16:05

這文章是轉(zhuǎn)來的,最早是一年前數(shù)碼多上原創(chuàng)測試文章,最近看到論壇不少人關心聽音樂音質(zhì)問題,重新從網(wǎng)上翻來,科普下.

喜歡音樂的,入個幾百塊的純音頻MP3吧,Android目前真心不合適聽音樂,音源,耳塞再牛逼也不行.

文章如下:

Android系統(tǒng)迅速崛起，超越iOS和Symbian成為第一大智能設備操作系統(tǒng)，它的占有率還有迅速擴張的趨勢，將有大量的多媒體設備采用這個系統(tǒng)，那么Android是否適合作為影音設備的操作系統(tǒng)使用呢？我們今天就來了解一下Android的音頻架構(gòu)。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲安卓系統(tǒng)

　　Android 基于Linux，我們先來了解一下Linux的特點。Linux使用ALSA作為其音頻架構(gòu)，其全稱Advanced Linux SoundArchitecture，即高級Linux聲音架構(gòu)的意思，在2.6核心之后，ALSA成為了Linux系統(tǒng)默認的音頻子架構(gòu)。取代了之前的OSS[Open Sound System，開放式聲音系統(tǒng)。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Linux ALSA音頻架構(gòu)示意

　　ALSA并不太好理解，它首先是一個驅(qū)動庫，包含了大量的聲卡設備的開源驅(qū)動，并提供了核心層API與ALSA庫通信，而ALSA庫則是應用程序訪問和操控音頻硬件的中間層，這個中間層有標準接口，開發(fā)者可以無須考慮硬件差異性進行開發(fā)，它對提升開發(fā)效率是大有幫助的。ALSA可以向下兼容OSS，因為OSS已經(jīng)被淘汰，其兼容的工作模式不再討論。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Android 系統(tǒng)下的ALSA庫文件

　　這個體系被繼承到了Android當中。在Android2.2[含之前，系統(tǒng)文件夾中能找到一個LibAudioALSA.so的文件，這就是ALSA庫文件，其他應用程序調(diào)用它，與聲卡設備進行指令和數(shù)據(jù)通信。Android音頻架構(gòu)與Linux的并無本質(zhì)區(qū)別。

　　在桌面版本的Linux當中，為了兼容各類聲卡，Linux也設置了一個SRC[Sample RateConverter，采樣頻率轉(zhuǎn)換的環(huán)節(jié)，當當前采樣率低于48KHz時強制SRC到48kHz輸出。這個SRC環(huán)節(jié)位于ALSA的插件模塊中的混音器部分。Android針對這個進行了改進。

　　什么是SRC？SRC即Sample Rate Converter，中文意思為采樣頻率轉(zhuǎn)換。它被聲卡愛好者所關注，大部分發(fā)燒友視SRC為音質(zhì)殺手。

　　Android增加了一個AudioFinger，這個可以簡單的理解為Android的ALSA音頻子系統(tǒng)的標準化的插件模塊，它包含了AudioMixer[混音器、AudioResampler[重采樣等子模塊，AudioResampler即我們理解的SRC，Android換了一個新名稱而已。針對SRC，Android做了改進，但改進并不是以去除SRC為目的，而是修改了默認的輸出頻率，Android的SRC目標采樣率為44.1kHz，非該值的采樣率都將SRC處理。例如播放48kHz采樣率的信號，輸出的最終是44.1kHz，這對音質(zhì)將產(chǎn)生負面影響。這個可以通過測試證明。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Meizu 魅族 M9 智能手機-頻率掃描，錄音端增益20dB 科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Meizu 魅族 M9 智能手機-48kHz頻率掃描，錄音端增益20dB　　對比這一組結(jié)果就能看出SRC對音質(zhì)的破壞性。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Huawei 華為 U8800 智能手機-48kHz頻率掃描科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Lenovo 聯(lián)想樂Pad 平板電腦-48kHz頻率掃描科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Malata 萬利達 Zpad T8 平板電腦-48kHz頻率掃描科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲SmartQ 智器 T10 平板電腦-48kHz頻率掃描　　這問題不只是魅族 M9存在。幾乎存在于所有的Android設備當中。

　　ALSA是一個針對Linux 桌面版本設計的音頻架構(gòu)，它實際上是不適合智能終端設備的，起碼里面大量的開源驅(qū)動代碼是可以去除的，對與Android來說，這些都是廢代碼。從Android2.3起，啟用了一個新的音頻架構(gòu)。它放棄了一直使用的ALSA架構(gòu)，因此系統(tǒng)文件夾中，也不再有LibAudioALSA.so這個文件。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Android2.3的系統(tǒng)文件夾下已經(jīng)沒有了ALSA庫文件科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Android 2.3后的音頻架構(gòu)示意

　　Android2.3起，架構(gòu)已經(jīng)做了修改，在針對內(nèi)部代碼進行了優(yōu)化，去除了冗余代碼，理論上讓系統(tǒng)能變得更加高效，可以將新架構(gòu)理解為一個精簡的或者為智能終端設備定制的ALSA架構(gòu)。遺憾的是，它同樣存在SRC嚴重劣化的問題，通過測試可以證明。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲HTC HD2 @Android2.3 智能手機-48kHz頻率掃描　　測試可以發(fā)現(xiàn)，Android 2.3的新架構(gòu)對音質(zhì)起不到正面作用。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲ASUS 華碩 Eee Pad Transformer TF101 平板電腦-48kHz頻率掃描　　Android 3.0專門為平板電腦設計，影音體驗變得更加重要了，是不是新系統(tǒng)在音質(zhì)方面會有新的的進步呢，測試結(jié)果依然是令人失望的。

　　Android系統(tǒng)將采樣率同一為44.1kHz輸出，這造成了諸多限制，它將無法實現(xiàn)96kHz、192kHz高清音頻節(jié)目的良好回放，大量視頻節(jié)目源自DVD或者藍光碟，其采用率多為48kHz，Android設備在回放這些視頻節(jié)目時，音質(zhì)也將大打折扣。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲安卓系統(tǒng)

　　理論上軟件SRC可以通過更換算法來實現(xiàn)音質(zhì)提升，但卻不太現(xiàn)實，智能終端所采用的CPU多為ARM，ARM芯片的浮點運算力有限，而SRC需要大量的浮點運算的資源，即便有了高質(zhì)量的SRC算法，其運算也是以犧牲設備性能和耗電量為代價的，實用性差。

　　從Android的音頻架構(gòu)及流程分析，可以認為，播放44.1kHz采樣率的音樂節(jié)目時，不會引發(fā)SRC，音質(zhì)因此可以獲得保證，理論上確實如此。但它同樣存在問題，不管是之前的ALSA架構(gòu)還是Android2.3之后改良的架構(gòu)，其驅(qū)動庫都位于核心層，也就意味著音頻設備廠商、用戶無法象PC平臺那樣安裝驅(qū)動來改善音質(zhì)。實際測試也表明，Android設備音質(zhì)普遍偏差，Soomal有大量測試可以證明。

　　我們再把目光投向iOS，iOS非常封閉，我們甚至無法獲知其架構(gòu)的具體構(gòu)成，但iOS設備不存在硬件設備多樣性的問題，因此要實現(xiàn)更好音質(zhì)也會更加簡單。iOS可以實現(xiàn)針對性的開發(fā)和改良，以實現(xiàn)更好的音質(zhì)。實際情況也是如此，目前為止，還沒有一款Android設備的音質(zhì)可以媲美任意一款iOS設備，這種差距，我們認為不是來自硬件，而是操作系統(tǒng)。科普貼關于Android的音頻SRC處理,音質(zhì)問題

▲Android高清影音播放器

　　Android音頻架構(gòu)的局限性也使得其難以成為優(yōu)質(zhì)的影音平臺，如果你希望設計一款基于Android的高清影音播放器，那么首先需要做的不是設計硬件，而是去修改現(xiàn)有架構(gòu)的不足，或者干脆設計一個專用的架構(gòu)來取代Android的通用架構(gòu)。從源代碼分析，Android和原生的Linux底層能支持各種采樣率，開源也使得其具有改造基礎，因此，在技術實力強勁的公司手里，Android也可以烏雞變鳳凰。高通芯片組與Android音頻系統(tǒng)缺陷測評分析2011年07月14日17:18數(shù)碼多我要評論(5)

字號：T|T

Qualcomm高通公司是目前Android智能手機上最為知名的ARM架構(gòu)的處理器和芯片方案硬件提供商，高通公司的Snapdragon系列中的QSD8250是首個實現(xiàn)1GHz主頻的ARM處理器。在Android手機中，高通的方案最為常見，在混亂的Android產(chǎn)品中高通芯片組擁有相對較好的兼容性。但是，經(jīng)過我們對采用高通芯片的手機的測試發(fā)現(xiàn)，它的音頻子系統(tǒng)部分存在缺陷。而這個缺陷，在Android系統(tǒng)下又恰好、不幸的被無情放大。我們測試了包括摩托羅拉XT316[MSM7227，ARM11架構(gòu)、華為U8800[MSM7230，HTC Desire Z使用同樣芯片、HTC Desire HD[MSM8255]、聯(lián)想樂Pad[QSD860A]、HTCSensation[MSM8260]和一款特殊的HTC HD2[QSD8250WM6.5WP7Android 3操作系統(tǒng)共六款使用高通芯片的手機或平板電腦，覆蓋了高通從ARM11到全系列Snapdragon所有芯片[不包含因為手機網(wǎng)絡制式不同的型號，如CDMA網(wǎng)絡。它們都存在同樣的問題。是什么原因?qū)е赂咄⊿napdragon全系列都會存在如此問題？它會帶來怎樣的影響？與Android搭配的高通產(chǎn)品為什么問題會加重？我們來一一分析。科普貼關于Android的音頻SRC處理,音質(zhì)問題

高通Qualcomm公司LOGO 科普貼關于Android的音頻SRC處理,音質(zhì)問題

高通+Android=音質(zhì)悲劇？我們的測試目的和方法發(fā)現(xiàn)高通芯片組音頻系統(tǒng)的缺陷，當然不是我們測試的目的，我們也沒有如此神通能無緣無故發(fā)現(xiàn)芯片級的設計缺陷。從2010年，Soomal進行耳機放大器、聲卡等測試以來，我們一直堅持使用一套固定的測試方法，對測試對象的信號輸出能力進行客觀分析測試。這套測試方法，雖然不能完全判斷它的系統(tǒng)是否足夠優(yōu)秀，但對于系統(tǒng)缺陷的判斷則從原理、過程、客觀結(jié)果來說是準確無誤。大家可以簡單的理解，如果與我們測試的20Hz-20KHz頻率掃描信號的光譜圖發(fā)生重大偏差，它的系統(tǒng)一定存在問題，聲音表現(xiàn)不可能好，而至于問題嚴重性，是如何造成的，同樣可以通過一些特征來分析。當我們測試第一款、甚至到第三款高通芯片組手機時，都并沒有確定它的問題所在，但通過Windows Phone 7、Windows Mobile系統(tǒng)，我們最終確定了結(jié)論。當然，我們發(fā)現(xiàn)問題，并不是要打擊高通，和使用高通芯片的手機，我們只是提出問題，并幸運的找到了問題出現(xiàn)的原因。作為高通來說，修正這個缺陷并沒有太大難度。為了更好閱讀文章，我們我們接下來再次講解一下頻率掃描光譜圖的閱讀方法。科普貼關于Android的音頻SRC處理,音質(zhì)問題

頻率掃描測試標準信號-20Hz-20KHz如圖所示，大家看到一張分為上下兩部分[代表左右聲道的兩條具有一定角度的直線，它存在于一個橫坐標為時間縱坐標為頻率的二維坐標空間內(nèi)。它表示的是，一個標準測試信號的光頻譜分析圖。它是一個從20Hz-20KHz頻率范圍內(nèi)的正弦波掃描圖，我們設置整個過程的時間為10秒。而光的強度，代表了信號的強度。由于，大家看到這張圖是我們生成的標準信號，所以大家發(fā)現(xiàn)只有兩條光亮的直線，而沒有其他弱信號出現(xiàn)，而且大家注意，它的背景是非常黑的，這代表整個頻率范圍內(nèi)，噪聲非常非常小。科普貼關于Android的音頻SRC處理,音質(zhì)問題

Apple蘋果iPodClassic1代80G-頻率掃描

再來看另一張圖，這是來自于iPod Classic的播放以上測試信號我們錄制得到的結(jié)果分析圖。與原信號相比，它出現(xiàn)了與主信號不同斜率的直線，這是諧波，但大家觀察它的顏色，偏淡藍色，說明信號強度很弱。而對比原始信號還發(fā)現(xiàn)，坐標低頻部分會出現(xiàn)一些頻率很低的淡紅色噪聲。大家還可以在我們測試過的MP3播放器、耳機放大器等文章中看到比iPod Classic強度稍大一些的諧波分布，但都在可接受范圍內(nèi)。明白了我們的測試方法，我們來看看高通芯片組的表現(xiàn)。我們的測試，使用專業(yè)級聲卡錄入的形式，并使用RMAA軟件測試和頻率掃描信號光譜分析兩種分析方式進行測試。在這里，我們不一一列舉RMAA的測試成績，大家可以參考每一款手機的音質(zhì)測評報告，而我們列舉的是所有我們測試過高通芯片組的頻率光譜分析圖。由于圖片縮放變得較小，我們放大其中一張來說明它們的特征。需要大家注意的是，這些測試均在16bit 44.1KHz規(guī)格下完成。科普貼關于Android的音頻SRC處理,音質(zhì)問題

Qualcomm高通芯片音頻子系統(tǒng)頻率掃描光譜圖科普貼關于Android的音頻SRC處理,音質(zhì)問題

HTCDesireHD[T-MobileG10]智能手機-頻率掃描從圖片很容易發(fā)現(xiàn)，高通所有芯片的噪聲都擁有同樣特殊的分布規(guī)律，這種規(guī)律在便攜播放器、聲卡、耳放等我們測試過所有產(chǎn)品中從來沒有出現(xiàn)過。這種規(guī)律，主要表現(xiàn)在它會出現(xiàn)與主信號平行的噪聲分布，且噪聲強度較強，在中高頻部分噪聲分布也開始雜亂。我們最初并不能確定，這是Android的問題，或是高通的問題。直到我們進行以下兩個測試。第一，我們發(fā)現(xiàn)在Android系統(tǒng)下測試44.1KHz信號的Tegra2、AML8706等芯片的機器結(jié)果與高通芯片沒有任何相似之處；第二，來自于“神機”HTC HD2在Windows Phone 7和WindowsMobile6.5下的測試。科普貼關于Android的音頻SRC處理,音質(zhì)問題

HTCHD2WindowsPhone7-頻率掃描@16bit48KHzMP3 科普貼關于Android的音頻SRC處理,音質(zhì)問題

HTCHD2@WindowsMobile6.5-頻率掃描@16bit48KHz這里看到的測試圖，與上兩張的測試環(huán)境不同，但與上圖中某個測試環(huán)境相同。它是HTC HD2手機在Windows Phone 7系統(tǒng)下，播放16bit 48KHz測試信號時的結(jié)果。同樣是HD2手機的QSD8250芯片，但高通芯片存在特有的噪聲分布消失了。我們看到一張非常正常的頻率掃描光譜圖。原因非常明顯，高通芯片在硬件部分存在44.1KHz的src問題。如果大家還信不過HD2是因為破解運行的Windows Phone 7，那就看看HD2在原生系統(tǒng)Windows Mobile 6.5下的表現(xiàn)，結(jié)果和Windows Phone 7一致。

高通音頻子系統(tǒng)于Android2.3的src示意圖科普貼關于Android的音頻SRC處理,音質(zhì)問題

高通音頻子系統(tǒng)@Android2.2[和更低版本的src示意圖大家也許已經(jīng)發(fā)現(xiàn)問題是如何發(fā)生的。從工作流程圖來看，系統(tǒng)中軟件播放節(jié)目源，將信號轉(zhuǎn)交操作系統(tǒng)驅(qū)動層，操作系統(tǒng)輸出后，轉(zhuǎn)交硬件部分最后輸出。在高通芯片組的Android手機中，Android系統(tǒng)如果遇到48KHz信號，會發(fā)生強制src到44.1KHz，而后交給高通芯片，高通芯片硬件遇到44.1KHz信號，再強制src到48KHz輸出。這是最悲慘的過程。當你播放一段視頻時，大多會遇到這樣的情況，因為目前視頻中音軌多數(shù)使用48KHz的采樣標準。另一種情況是，軟件播放的節(jié)目源為44.1KHz，Android支持，自然沒有問題，但高通芯片硬件層不支持，它還是要強制src至48KHz輸出。所以，就看到了我們提供的那張測試“全家福”的慘劇。科普貼關于Android的音頻SRC處理,音質(zhì)問題

HTCDesireHD[T-MobileG10]智能手機-頻率掃描@16bit48KHz無論是Android操作系統(tǒng)強制src或是高通芯片強制src，都會帶來明顯的信號損失和大量噪聲產(chǎn)生。而Android的src問題顯然要比高通更為嚴重，但高通芯片不支持44.1KHz輸出，發(fā)生的強制src，雖然從src過程來看遠好于Android操作系統(tǒng)軟件所做的，但仍是明顯缺陷和不足。作為一款如此多移動設備使用的芯片組，竟然無法支持最常見的音樂制品采用的44.1KHz的標準，并采用src的方式提供支持，實在有些說不過去。而所有的44.1KHz信號都要通過src后來輸出，這是需要通過處理器計算完成的，必定增加芯片耗電量，這種設計實在是出力不討好。也許高通芯片組，本以為自己的優(yōu)勢在48KHz上，那播放視頻時自然不會有問題了？可惜！在Android上高通芯片硬件是無法得到它的。高通芯片組問題影響 科普貼關于Android的音頻SRC處理,音質(zhì)問題

Motorola摩托羅拉XT316智能手機-Qualcomm高通MSM7227

staticfield · 發(fā)表于 2014-2-25 17:42

大贊科普貼

› 智能電視盒 / 安卓TV機頂盒區(qū) › 華為盒子論壇