深度剖析 Android音频系统解析与改进

来源:htcbbs.net 发布者:xinxintip 版权:转载

Android是用了一个Google自己开发的中间层API来让APP和声音驱动(ALSA或者HAL封闭驱动)通信的。在早期,它是个ALSA的插件;现在则命名为AudioFlinger。但是安卓音质根本问题在哪?

Android音频系统的改进设想和展望:

拥有Beats音效的HTC One X当然无需担心其音质,目前Tegra 3最高端的机器就是已经升级至HTC Sense 4.0华丽界面和Android 4.0.3 ICS系统的四核旗舰HTC One X!需要购港行HTC One X的朋友可以去52htc.net看看,他们能提供全新不拆封原包装保证正品,并支持免费ROOT升级刷机服务。

在这里先说明,本人并没有仔细地去看Android和PulseAudio的音频具体源代码和实现,欢迎指正。

从硬件用料上看,Android能不能做好音质?答案当然是可以的!MOTO的手机音质就做得不错。另外,W700也还可以(输出电平小了点,导致指标不好看)。

从软件和系统上看?答案是NO。高延迟,劣质SRC,这些玩意只能毁了音乐和音频应用。

简单地说,Android是用了一个Google自己开发的中间层API来让APP和声音驱动(ALSA或者HAL封闭驱动)通信的。在早期,它是个ALSA的插件;现在则命名为AudioFlinger。

无论是什么方式,实际上APP是以访问中间层API的方式让自己发出声音的,而这个API,却成了Android整个音频系统的噩梦。

噩梦一:SRC

实际上个人觉得最不可思议的是,AudioFlinger为什么要做强制SRC?要知道,ALSA是支持硬件SRC的(早期ALSA标准API本身却不支持,这个设计也是超级傻,具体表现在如果你在Linux下使用某个使用早期ALSA API的音乐播放器,播放和硬件采样率不匹配的音频档案,就会报错,同时期的PulseAudio API反而支持……),可实际上Android4.0后ALSA已经是最新的版本了。现在的Linux通过ALSA驱动做硬件SRC也不会是太大问题,当然音质比较一般(相当于高通,全志等芯片组在44.1KHz音源下的音质)就是了。

可是,AudioFlinger为什么自身要做一个强制重采样行为呢?个人预计,实际上AudioFlinger只是Android早期音频系统API接口的继承和扩展,它遗留了太多由于早期ALSA的不足而提供的“临时解决方案”,Android1.X的时候,ALSA相对现在也是非常的糟糕,google不得已写了个SSRC插件来解决当时ALSA不支持非匹配采样率无法发声的问题。至于Google为什么现在不解决,答案很明显:原来的代码都是临时的无证程序员写的,Android有个叫中子播放器的软件就能提供相对高质量的SSRC ,google没道理写不出来。但是那样对于现在版本的ALSA能力来说简直是多余的行为,还会导致声音延时和性能损失。

噩梦二:系统资源占用和延迟

这两个为什么放到一起说?因为,高延迟意味着系统IO动作多。Google“聪明”地做了一套soundfx系统,给所有音频做预处理,比如频响均衡器(EQ),重采样后对高频进行衰减等,这些接口为开发第三方音频应用提供了方便,却导致Android的音频性能出现了极大地负载和延迟,特别是游戏应用。Android的音频接口有两个,一个是用来播放音乐,这个接口提供了较大的缓冲,延迟也比较大;另一个则是用来做实时事件音效的处理(比如乐器声,效果音等等),将声音读入高速缓存(只能缓存10秒左右),然后进行处理。Google标榜这个为“低延迟”,可实际上因为API对音频做了大量的预处理,导致就算开发人员使用高速缓存接口,出了触屏感应处理外,音频也会有180ms以上的延迟,所以一些所谓的乐器演奏软件或者音乐游戏,基本就是Android劣势的彻底体现,这样的问题也导致Android无法进行音频处理应用。

PulseAudio简介

Collabora是一个开源系统解决方案的开发商,对于个人用户是免费开源的(对厂商似乎要收费,所以,Android开发厂商对此没兴趣掏钱)。PulseAudio是和AudioFlinger一样的音频系统API,PulseAudio并不完美,但是并不会有AudioFlinger的那两个致命问题。而且,HP webOS 、N900/Maemo5、N9/MeeGo都采用了PulseAudio作为系统音频API。

PulseAudio能解决的问题:

1、不会强制重采样,而是交由驱动来解决,避免了AudioFlinger极度劣质的SSRC。

2、不做预处理,极大减少音频延迟和系统开销(高速缓存处理延迟可以降低至20ms,虽然并不算很好,但是对于移动装置和平板来说已经足够)。

这看起来很美,不是么?可是为什么没有厂商积极面对呢?实际上,更换Android的音频系统,远远不像换衣服那么简单!

授权移植费用

虽然PulseAudio是开源软件,但开源不等于免费,PulseAudio很可能是针对企业收费的。这里会导致一个两头难的问题:大厂商不掏钱就用,可能会吃官司;而用了,会导致一系列连锁反应,这个会在后面介绍。小厂商可以完全不鸟什么商业授权,但是本身的孱弱的开发能力不足以对Android做二次开发。

原有的应用音频相关功能全部报废

更换音频系统是个大工程,因为现在Android所有的应用都是基于AudioFlinger的,如果更换为PulseAudio,则现有的应用完全无法在新系统上使用,原有的应用匹配新的音频API可以说是一个浩瀚的工程,而普通用户如果强制在自己的Android装置上安装PulseAudio,则可能要面对的是连音乐没法听,电话都没法打的风险。这样巨大的成本和风险,是厂商和用户都无法承受的。当然,PulseAudio和AudioFlinger可以共存,可共存的代价就是更耗资源更耗电,和更可怕的系统冲突(想象一下两个不同的API同时请求驱动所导致的风险)。

开发成本,有限的应用资源

如果真有一个有心的厂家思路广欢乐多,在自己的产品上使用了PulseAudio,那么厂商最少必须重写一套通信应用和音乐播放器。而厂商也会很遗憾地告诉用户,你们在切水果弹小鸟的时候,都不会有声音。想要正常发声,必须得移植大量现有的Linux应用软件,而这些应用软件不说本身代码或者用户体验怎么样,针对台式机和移动装置毕竟是完全的两码事。

但是,这并不是说PulseAudio取代AudioFlinger完全没戏,厂商可以再写一个“AudioFlinger”语法的PulseAudio API兼容现有的应用,虽然会花点时间也有不小风险,这并不算很难。可是,就是没有厂家考虑过。毕竟这方面用户很难以这个为理由把厂家弄上315晚会,厂商也不会有兴趣。所以高通的音频系统再糟糕,如果你打算和高通沟通的话,他也只会认为你需要广告费了而已。

PulseAudio不能解决的问题:

高质量音频应用,就必须避免SRC,codec的硬件能力还不足以提供优质的SRC,所以,根据音源改变采样率才是最佳的选择,这点PulseAudio是做不到的。但是ALSA可以,实际上ALSA是可以和Win7一样实时更改采样率的,不过Android和PulseAudio并没有提供这个功能的API,如果真为了音质,这个是应该做到的。

综上所述,Android并不是不能做好音频,而是由于google一直在使用错误的方法处理音频,而这个错误已经延续到了现在几乎难以挽回。可是现在不改正,这个巨大的成本还会像滚雪球一样倍增,因为google和开发人员的一时之便,导致现在的Android平板音质连几年前的MP3MP4都不如,这是时代的倒退。

Android音频系统的改进设想和展望(2)

不过由于写得太匆忙,没有认真去分析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更遥远。
 

关注【HIFI音响】公众平台

    ID:HIFI中国音响网 ID:hifidiy_2016