alsa-lib与alsa-driver的关系

alsa-driver与alsa-lib之间的关系
alsa声卡驱动体系中的alsa-driver与alsa-lib是整个alsa音频驱动的中间层，
alsa app
--------------------
alsa lib
--------------------
alsa driver
--------------------
alsa device driver

上面的alsa app只需要集中注意力到应用逻辑,
下层的alsa device driver也只需要关注如何实现alsa driver要求的接口

这两层间的接口确实是在pcm_hw.c(lib)和pcm_native.c(driver)中实现的,如snd_pcm_writei函数最终是调用了pcm_hw.c中的ioctl函数,这个函数是通向driver层的pcm_native.c的入口.

但有一个好像是例外的,就是snd_pcm_open,我没有找到他从lib到driver的接口,不知道在pcm_native.c里面有一个snd_pcm_open是不是就是对应这个函数.


alsa的中断放音模式,还有一种是非中断放音模式的,就是open-->设置参数-->writei,就可以了,


snd_pcm_lib_write_transfer这个一般只是进行dma enqueue，dma完成后的中断处理ISR(arch/xx/mach/xx/dma.c)后调用dma设置时的callback。

此文章为其他文章剪辑，不完整，正在进一步研究，完善中。。。

alsa lib源码分析

    使用ALSA lib进行音频播放器开发的朋友都知道，ALSA的配置文件alsa.conf定义了一些简单的语法，通过这些语法记录了alsa环境变量。该文件在/usr/share/alsa/alsa.conf.该文件开头处包含了用户可以配置的hook.用户自定义的配置信息可以保存在/etc/asound.conf或~/.asoundrc里，当然也可以自己定义的位置。
我们感兴趣的是,alsa lib是如何解析这些配置的。首先我们可以从使用alsa lib时，最先的入口函数snd_pcm_open处开始说起：
int snd_pcm_open(snd_pcm_t **pcmp, const char *name,
snd_pcm_stream_t stream, int mode)
{
int err;
assert(pcmp && name);
err = snd_config_update();
if (err < 0)
return err;
return snd_pcm_open_noupdate(pcmp, snd_config, name, stream, mode, 0);
}
其中调用了函数snd_config_update(),这个函数就是加载alsa的配置文件中配置信息的。这个函数直接调用了snd_config_update_r,并以snd_config,snd_config_global_update为参数。这两 个参数都是全局变量(snd_config_global_update 为静态)，定义在conf.c中。初始值为0：
2616: snd_config_t *snd_config = NULL;
2632:static snd_config_update_t *snd_config_global_update = NULL;
snd_config_update_r还有第三个参数cfgs，是包含配置文件名的字符串，snd_config_update调用它时没有传递该参数，所以为空。
snd_config_udpate_r首先分析第三个参数cfgs,如果为空，就获取系统环境变量ALSA_CONFIG_PATH_VAR值，如果还是为空，就取ALSA_CONFIG_PATH_DEFAULT.
然后提取cfgs里的文件名。注意cfgs可以包含多个文件名，以：或空格分开。并把每个文件的文件信息保存在
snd_config_update_t变量local中，其成员count记录了有多少个文件，finfo则是对应的文件信息链表。
接下来分析第二个参数update，如果该参数值为空（前面提到过，最开始是为空），就重新去读配置文件，否则与local变量比较，如果发现不一样（配置文件被修改过）,也会跳转到重读配置文件的代码。
重新读取配置文件的代码主要做三件事，第一，以第一个参数snd_config_t * top为参数调用snd_config_top(top);第二，打开local中保存的每一个配置文件，并调用snd_config_load(top,in),其中in是snd_input_t类型