alsa sample rate跟踪 <1>
本计划全部放在一篇中,后来发现太长。
因此截取成四篇,一口气看800多行,确实够烦的!
之前以为alsa lib中的rate plugin之所以被调用,是因为在asound.conf中指定了硬件的sample rate,例如rate 48000。
但实际测试下来,发现不是这么回事。
无论asound.conf中是否有rate 48000,驱动中得到的params中的rate都是48000。
这是什么原因呢?一时想不明白。
先把rate经过的路线画出来吧。
rate包含在params中,那就顺着params看吧。
我们直接接触的是声卡驱动,params相关的函数就是XXXX_hw_params了。
在函数XXXX_hw_params中把sample rate打印出来,发现已经是48000了。
通过dump_stack把kernel中的调用堆栈打印出来,如下:
[ 65.259240] [<8003bd9c>] (unwind_backtrace+0x0/0xf8) from [<7f312248>] (imx_3stack_surround_hw_params+0x38/0x4c8 [snd_soc_imx_saf7741])
[ 65.274646] [<7f312248>] (imx_3stack_surround_hw_params+0x38/0x4c8 [snd_soc_imx_saf7741]) from [<7f1c3d50>] (soc_pcm_hw_params+0x4c/0x1a8 [snd_soc_core])
[ 65.291480] [<7f1c3d50>] (soc_pcm_hw_params+0x4c/0x1a8 [snd_soc_core]) from [<7f116e6c>] (snd_pcm_common_ioctl1+0x844/0xea0 [snd_pcm])
[ 65.304804] [<7f116e6c>] (snd_pcm_common_ioctl1+0x844/0xea0 [snd_pcm]) from [<7f1178f0>] (snd_pcm_playback_ioctl1+0x40/0x3e0 [snd_pcm])
[ 65.317841] [<7f1178f0>] (snd_pcm_playback_ioctl1+0x40/0x3e0 [snd_pcm]) from [<800f0000>] (do_vfs_ioctl+0x80/0x54c)
[ 65.328629] [<800f0000>] (do_vfs_ioctl+0x80/0x54c) from [<800f0504>] (sys_ioctl+0x38/0x5c)
[ 65.337306] [<800f0504>] (sys_ioctl+0x38/0x5c) from [<800350c0>] (ret_fast_syscall+0x0/0x30)
我们只关心params相关。
snd_pcm_common_ioctl1的部分内容:
static int snd_pcm_common_ioctl1(struct file *file,
struct snd_pcm_substream *substream,
unsigned int cmd, void __user *arg)
{
...
case SNDRV_PCM_IOCTL_HW_PARAMS:
return snd_pcm_hw_params_user(substream, arg);
...
}
函数snd_pcm_hw_params_user的实现:
static int snd_pcm_hw_params_user(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params __user * _params)
{
struct snd_pcm_hw_params *params;
int err;
params = memdup_user(_params, sizeof(*params));
if (IS_ERR(params))
return PTR_ERR(params);
err = snd_pcm_hw_params(substream, params);
if (copy_to_user(_params, params, sizeof(*params))) {
if (!err)
err = -EFAULT;
}
kfree(params);
return err;
}
在kernel中被传来传去的params原来就诞生在snd_pcm_hw_params_user函数中。
结合函数snd_pcm_common_ioctl1可知,user层调用了一个ioctl,command为SNDRV_PCM_IOCTL_HW_PARAMS,并将params作为arg参数传给内核。
内核中将arg重新copy到params并使用。
内核中的代码还是比较清晰的。
阅读上面dump_stack的调用堆栈可知,内核中将params传递给函数XXXX_hw_params之前,并没有修改params。
也就是说XXXX_hw_params中的sample rate为48000,并不是在内核中产生的。
那就继续往上追踪,也就是alsa lib了。
alsa lib中的代码不是那么清晰。
当时,不是说代码写的不好(呵呵,能实现这些东东的,可都是大牛),是因为alsa lib中要处理很多种情况,并且要解析asound.conf文件,
根据音频文件参数,硬件参数,以及alsa配置文件(asound.conf是其中之一)来决定需要进行什么样的处理。
呵呵,说到底还是没能对alsa lib完全理解,所以它在面前仍然是一个庞然大物,没有庖丁解牛的感觉。
一时半会也不能把alsa lib全部搞透,暂时也没时间详细研究,先只关系params吧。
在alsa lib中搜索SNDRV_PCM_IOCTL_HW_PARAMS,发现其出现的地方:
static inline int hw_params_call(snd_pcm_hw_t *pcm_hw, snd_pcm_hw_params_t *params)
{
/* check for new hw_params structure; it's available from 2.0.2 version of PCM API */
if (SNDRV_PROTOCOL_VERSION(2, 0, 2) <= pcm_hw->version)
return ioctl(pcm_hw->fd, SNDRV_PCM_IOCTL_HW_PARAMS, params);
return use_old_hw_params_ioctl(pcm_hw->fd, SND_PCM_IOCTL_HW_PARAMS_OLD, params);
}
上溯:
static int snd_pcm_hw_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t * params)
{
snd_pcm_hw_t *hw = pcm->private_data;
int err;
if (hw_params_call(hw, params) < 0) {
err = -errno;
SYSMSG("SNDRV_PCM_IOCTL_HW_PARAMS failed (%i)", err);
return err;
}
params->info &= ~0xf0000000;
params->info |= (pcm->monotonic ? SND_PCM_INFO_MONOTONIC : 0);
err = sync_ptr(hw, 0);
if (err < 0)
return err;
if (pcm->stream == SND_PCM_STREAM_CAPTURE) {
snd_pcm_set_appl_ptr(pcm, &hw->mmap_control->appl_ptr, hw->fd,
SNDRV_PCM_MMAP_OFFSET_CONTROL);
}
return 0;
}
原来是在snd_pcm_hw_hw_params中发起的ioctl。
snd_pcm_hw_hw_params赋值给了结构体snd_pcm_hw_ops:
static const snd_pcm_ops_t snd_pcm_hw_ops = {
...
.hw_params = snd_pcm_hw_hw_params,
...
}
看代码最怕这种,给函数都带上相同的面具,让你摸不清谁是谁。
揭开它们面具最好的方法就是让它们都报上名来,呵呵。
在所有的hw_params函数中各加一句log,把各自函数名打印出来,顺便把进入各函数时的sample rate也打印出来,以方便我们查询sample rate究竟是在哪儿被改变的。
结合kernel中代码,可知根据params取得sample rate的方式为:
(¶ms->intervals[SNDRV_PCM_HW_PARAM_RATE - SNDRV_PCM_HW_PARAM_FIRST_INTERVAL])->min
通过打印log,发现hw_params被调用的信息如下:
snd_pcm_hw_params - rate=48000
_snd_pcm_hw_params - rate=48000
snd_pcm_hw_hw_params - rate=48000
snd_pcm_hw_params - rate=16000
_snd_pcm_hw_params - rate=16000
snd_pcm_plug_hw_params - rate=16000
_snd_pcm_hw_params - rate=16000
snd_pcm_rate_hw_params - rate=16000
snd_pcm_generic_hw_params - rate=48000
_snd_pcm_hw_params - rate=48000
snd_pcm_direct_hw_params - rate=48000
函数snd_pcm_hw_params的实现:
/** \brief Install one PCM hardware configuration chosen from a configuration space and #snd_pcm_prepare it
* \param pcm PCM handle
* \param params Configuration space definition container
* \return 0 on success otherwise a negative error code
*
* The configuration is chosen fixing single parameters in this order:
* first access, first format, first subformat, min channels, min rate,
* min period time, max buffer size, min tick time
*
* After this call, #snd_pcm_prepare() is called automatically and
* the stream is brought to \c #SND_PCM_STATE_PREPARED state.
*
* The hardware parameters cannot be changed when the stream is
* running (active). The software parameters can be changed
* at any time.
*/
int snd_pcm_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t *params)
{
int err;
assert(pcm && params);
err = _snd_pcm_hw_params(pcm, params);
if (err < 0)
return err;
err = snd_pcm_prepare(pcm);
return err;
}
snd_pcm_hw_params与_snd_pcm_hw_params调用关系以及明了了。
接着要看看:
1、snd_pcm_hw_hw_params,snd_pcm_plug_hw_params,snd_pcm_rate_hw_params,snd_pcm_generic_hw_params和snd_pcm_direct_hw_params是如何被调用的。
2、以及snd_pcm_hw_params和几处单独的_snd_pcm_hw_params是如何被调用的。