本文系网友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更遥远。
偶尔才会有不同采样频率的音频同时发声的情况。例如听看视频（通常是48KHz的音轨）时后台某个IM软件的提示音（通常采样频率是22.05KHz）响了，这时SRC是不可避免的。
因此我认为移动操作系统首先需要能输入、输出不用采样频率、精度的音频，其次还应根据实际情况合理进行SRC。
例如播放44.1KHz的音乐时，提示音响了，即使提示音的采样频率是48KHz，也应该SRC至44.1KHz。而播放视频中48KHz的音轨时，提示音响了，即使提示音的采样频率是44.1KHz，也应该SRC至48KHz。换句话说，应该以前台应用的采样频率为基准。
——详细阅读
我再重申一次, 看看Beats能忽悠多少人, 你就能明白以Google的立场这根本就不是问题
举个我身边的例子, 我在公司用K702, 同事都表示听起来跟30元的飞利浦头戴没有区别
但是, 对Google来说, 这是根本不需要解决的问题, 你就看看HTC的Beats能忽悠多少人吧...
京公网安备 11011402011520号