Android音频系统的改进设想和展望 PulseAudio介绍

http://www.soomal.com/doc/10100002871.htm

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

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

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

• 相关文章
  《Qualcomm 高通芯片组与Android音频系统缺陷测评分析 》[作者: 赵宇为 ] 
  《聊聊Android的音频架构 》[作者: 夏昆冈 ] 
  

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

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

相关资料 收藏此图 相关图片

高通音频子系统于Android2.3的 SRC示意图

相关资料 收藏此图 相关图片

高通音频子系统@Android2.2[和更低版本]的SRC示意图

噩梦一：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《Android音频播放软件Neutron Music Player[中子播放器]音质测评报告 》[作者: 赵宇为 ] ，google没道理写不出来。但是那样对于现在版本的ALSA能力来说简直是多余的行为，还会导致声音延时和性能损失。

相关资料 收藏此图 相关图片

Ainol 艾诺 NOVO7 极光版 平板电脑-libaudiopreprocressing.so[音频预处理功能]

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

这两个为什么放到一起说？因为，高延迟意味着系统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 Logo 标志

授权移植费用

虽然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都不如，这是时代的倒退。