导读：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更遥远。