alsa sample rate跟踪 <1>

最新推荐文章于 2023-10-09 13:12:48 发布

njuitjf

最新推荐文章于 2023-10-09 13:12:48 发布

阅读量4.7k

点赞数

CC 4.0 BY-SA版权

分类专栏： Linux Audio

本文链接：https://blog.youkuaiyun.com/njuitjf/article/details/17752047

Linux Audio 专栏收录该内容

5 篇文章

订阅专栏

深入探讨ALSA中采样率的跟踪机制，通过分析代码路径和堆栈调用，揭示采样率的确定过程及ALSA如何处理asound.conf配置与驱动参数之间的关系。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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的方式为：
(&params->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是如何被调用的。