Android2.2、Android2.3 、Android4.0 audio hardware模块分析
从事Linux开发的工程技术人员都知道，ALSA是Advanced Linux Sound Architecture的简写，它现在很流行，起初使用在台式电脑上，随着嵌入式的发展，它有把触角伸入了新的园地，并且在这个新舞台上越来越受欢迎。ALSA很强大，功能很丰富，当然本身就比较庞大了一些。事情都是这样的，使用起来简单，就必然有个环节要付出艰辛, ALSA就干了这样一件事。在android2.2上，Google将其视为掌上明珠、座上宾，将其加入了maintree，因此在android2.2上，在hardware层，大多公司选择了ALSA作为跟driver打交道的帮手，当然也有高通这些公司，一直坚持自己私有的一套东西。当然android还是蛮开放的，允许你自己来选择、实现！在2.2上编译出来的共享库为alsa.XXX.so,xxx可以为产品名称，也可以使用default，随即就是alsa.default.so。
到了android2.3，变化了，ALSA被干掉了！！！可悲啊！Google居然写了自己的一套迷你接口！开源的ALSA虽然有很多东西你用不上，但是自己写一套迷你这样的接口也变成私有的了，不利于以后的发展，有一种忧虑是Google自己写的这一套东西能不能跟ALSA的release同步更新，能不能跟上这个脚本，这并非没有道理。如果使用Google写的迷你接口，就会出现driver还是使用ALSA的，user space使用Google的，感觉就是核是别人的，壳是自己的，这样工作是能工作，搭不搭啊？driver里出错了的情况下，Google的接口怎么办？没看见how to process，只是give up audio data。2.3里面对audio的操作，打开设备、关闭设备，非常频繁，不觉得很好。
笔者通过比较2.3的audiofliger跟2.2的audiofliger后，分析后认为，2.3可以把2.2使用ALSA的hardware layer的code完全merge到2.3来工作，因为在audiofliger中，调用hal layer的接口没有发生变化，也算Google留了一手吧！
到了最新的android4.0，Google整出来了一个tinyalsa，还稍微公道一点，还是沾上了alsa这几个字，只不过是tiny的。但是笔者分析了4.0的audiofliger后发现，audiofliger调用hal layer的接口发生了翻天覆地的变化，猛啊！4.0把play跟capture分得更开放了，自己管自己的，audiofliger都从原来3k来行，扩张到了5k多行，大动干戈啊！苦了的还是coder啊！从接口上来看，开放性更高了！当然hal layer需要大变样了！不过还是可以使用ALSA接口来实现。不管是ALSA，还是tinyalsa，归根结底是跟driver打交道的最后一关，跟hal layer的控制逻辑什么的关系不大，看到Samsung的参考代码就是使用了自己的一套实现。
下面笔者就来分析下android4.0的audiofliger如何调用hal layer功能代码的：
调用关系解析：
AudioFliger.cpp
static int load_audio_interface(const char *if_name, const hw_module_t **mod,
audio_hw_device_t **dev)
{
int rc;
/*decide audio.primary.XXX.so, XXX 为product名称，得到hw_module_t对象；
hw_get_module_by_class 来之于libhardware.so*/
rc = hw_get_module_by_class(AUDIO_HARDWARE_MODULE_ID, if_name, mod);
if (rc)
goto out;
/*Open hw device，这样就会call到上一步对象中的hw_module_methods_t中注册的open函数，这样就进一步细化注册了众多audio的hardware接口；
audio_hw_device_open 是inline函数，会call回mod的open*/
rc = audio_hw_device_open(*mod, dev);
LOGE_IF(rc, "couldn't open audio hw device in %s.%s (%s)",
AUDIO_HARDWARE_MODULE_ID, if_name, strerror(-rc));
if (rc)
goto out;
return 0;
out:
*mod = NULL;
*dev = NULL;
return rc;
}
分析清楚了这种关系，我们只要去完善hal layer的代码即可，选哪种方式实现，是你的自由！就以后代码的移植性、兼容性来说，我还是觉得ALSA更好一些，学习的资料也更多，碰到了一些问题，还能Google出来帮忙，用私有的，能实现，麻烦还是会有的！
一家之言，仅供参考！
