Linux 音频子系统分析3

最新推荐文章于 2025-06-16 22:14:14 发布

ListQueue

最新推荐文章于 2025-06-16 22:14:14 发布

阅读量1.2k

点赞数 30

CC 4.0 BY-SA版权

分类专栏： Linux内核子系统文章标签： linux 音视频运维

本文链接：https://blog.youkuaiyun.com/zouhaicheng/article/details/144710915

Linux内核子系统专栏收录该内容

199 篇文章

订阅专栏

Linux 音频子系统分析3（基于Linux6.6）---ALSA ASoC介绍

一、概述

1.1、ASoC的目标

ASoC的主要目标是提供对嵌入式系统（特别是SoC平台）中音频硬件的支持。这些平台通常具有集成的音频处理单元（如DAC、ADC、Codec等），并且与传统的PC音频硬件有显著的不同。

1.2、关键特点

模块化： ASoC设计时将音频硬件功能模块化，使得驱动程序可以针对每个硬件模块（如Codec、DMA、Dai等）单独开发。这样可以避免在不同硬件间的代码重复，从而简化驱动开发和维护。
分层结构： ASoC使用分层结构来管理音频设备的不同部分。通常，ASoC驱动程序会涉及以下几个关键组件：
- Machine Driver：负责连接和配置整个音频硬件平台，主要用于设置音频硬件和其他子系统（如I2S、PWM、DMA等）。
- Codec Driver：驱动音频编解码器（如DAC、ADC），通常涉及与外部音频设备的通信。
- Platform Driver：负责配置硬件平台的低级接口，通常用于控制数据传输和处理。
- Dai Driver：代表音频设备的一个接口或硬件组件，Dai（Digital Audio Interface）通常指的是音频的输入或输出路径，如I2S、PCM等。
音频流向管理： ASoC框架非常关注音频数据流的管理。它支持从内存到Codec的音频数据流传输，并且允许对音频路径进行配置和优化。例如，您可以配置音频流在不同模块之间的传输路径，以实现多通道音频处理。
硬件抽象： ASoC实现了硬件抽象，使得驱动程序能够以统一的接口来处理不同的硬件平台。尽管不同平台的硬件可能有很大的差异，但ASoC提供了统一的框架来简化驱动程序开发。

1.3、ASoC的组成部分

Machine Driver（机器驱动）：机器驱动是ASoC架构中的核心部分，负责配置和管理音频硬件的整体工作。它决定了如何将不同的音频组件（如Codec、DMA、I2S等）组合在一起。每个SoC平台通常会有一个独特的机器驱动，描述平台的硬件架构和音频流的路径。
Codec Driver（编解码器驱动）：编解码器驱动负责与实际的音频编解码硬件通信，通常用于控制音频信号的输入和输出（例如通过DAC、ADC）。它负责音频格式的转换、信号增益调整等。
Platform Driver（平台驱动）：平台驱动负责控制底层硬件资源的配置（如I2S总线、PCM设备、DMA引擎等），它是音频传输的桥梁，连接硬件平台和上层驱动。
Dai Driver（Dai驱动）： Dai驱动（Digital Audio Interface）表示一个音频输入或输出接口，通常用于指定I2S、PCM等数字音频接口的配置。一个平台可能会有多个Dai驱动，每个Dai负责一个输入或输出通道。
PCM Interface（PCM接口）： PCM（Pulse Code Modulation）是常见的音频格式，ASoC框架为不同的音频硬件提供了PCM接口支持。这允许用户空间通过ALSA API进行音频流控制。

1.4、ASoC工作原理

硬件设备初始化： ASoC驱动会初始化硬件设备，包括平台硬件、音频编解码器等。初始化过程通常由机器驱动（Machine Driver）负责，涉及配置设备的音频路径和相关资源。
数据流管理：音频数据通常从内存或其他设备流向编解码器（Codec）或其他音频接口。ASoC通过配置平台驱动和Dai驱动，确保数据的流动路径正确且高效。
音频控制： ASoC通过ALSA框架提供了音频控制接口，使得应用程序能够调节音量、采样率、通道数等音频参数。音频控制通常通过ALSA的mixer接口进行。
数据传输：数据通过I2S、PCM、DMA等接口传输。ASoC支持直接内存访问（DMA），使得音频数据传输更加高效。
协同工作： ASoC的各个驱动模块（机器驱动、平台驱动、Codec驱动、Dai驱动）协同工作，以确保音频数据流的顺畅、控制参数的正确传递，并确保硬件资源的正确配置和管理。

1.5、ASoC的优点

灵活性和扩展性：ASoC设计充分考虑了不同硬件平台的差异，提供了一个高度模块化的结构，使得不同硬件平台的音频驱动可以通过相对简单的修改进行适配。
性能：通过支持直接内存访问（DMA）和多通道音频流，ASoC能够高效地管理音频数据的传输，减少CPU负担。
支持多种音频设备：ASoC不仅支持基本的音频编解码器（Codec），还可以扩展支持其他音频硬件，如音频处理器、音频接口等。

ASoC是Alsa System on Chip的缩写，用于实现那些集成声音控制器的CPU，它的设计目标如下：

解耦codec， codec的驱动不依赖具体的平台。
简单易用的I2S/PCM配置接口，让soc和codec的配置相匹配。
动态的电源管理DAPM，实现对用户空间透明的电源管理，各个widget按需供电，实现功耗最小化。
消除pop音，控制各个widget上下电的顺序消除pop音。
添加平台相关的控制，如earphone, speaker。

二、ASoC架构

在这里插入图片描述
以播放为例, 在这样一个硬件结构下, 涉及到几个模块:

DMA : 负责把用户空间的音频数据搬移至I2S的FIFO.
I2S : 负责以某个采样频率、采样深度、通道数发送音频数据, 也叫dai (Digital Audio Interface).
AFIx : 负责以某个采样频率、采样深度、通道数接收音频数据, 也称作dai.
DAC : 并把数据通过DAC转换后送给耳机等播放.

为了解决复用性问题, 内核引入了ASoC架构，在底层ASoC抽象了如下三个模块:

模块	功能	编写者
Platform	负责DMA（Direct Memory Access）和I2S（Inter-IC Sound）控制。	CPU厂商
Codec	负责控制芯片的音频功能，包括 AFiX（音频接口扩展）和 DAC（数字模拟转换器）控制。	Codec厂商
Machine	描述电路板，指明使用的Platform和Codec，定义硬件配置。	电路板商

从数据结构的角度来说, ASoC核心层内部定义了如下数据结构, 注意它们是由核心层内部创建和维护的：

struct snd_soc_platform : 用于抽象一个platform, 作用是描述一个CPU的DMA设备及操作函数. 系统中可能有多个platforms, 它们都挂载在全局链表头static LIST_HEAD(platform_list)下面, 不同的platform以name区分.
struct snd_soc_codec : 用于抽象一颗Codec. 一颗Codec可能会有多个dai接口, 该结构体的作用是描述与具体dai无关的、Codec内部的工作逻辑, 例如控件/微件/音频路由的描述信息、时钟配置、IO 控制等. 系统中可能有多个Codecs, 它们都挂载在全局链表头static LIST_HEAD(codec_list) 下面, 不同的Codec以name区分.
struct snd_soc_dai : 用于描述一个dai, 既可以是CPU侧的dai(I2S), 也可以是Codec侧的dai(AFIx). 一颗CPU可能有多个I2S, 一个Codec也可能有多个AFIx, 因此系统中会有很多个dai, 它们都挂载在全局链表头static LIST_HEAD(dai_list)下面, 不同的dai以name区分.

从底层驱动的角度来说, ASoC定义了一些需要底层实现的interface以及相应的注册函数：

针对DMA (platform): CPU厂商需要填充struct snd_soc_platform_driver 和struct snd_pcm_ops, 然后调用snd_soc_register_platform向ASoC核心层注册, 例如atmel-pcm-pdc.c.
针对I2S (cpu_dai): CPU厂商需要填充struct snd_soc_dai_driver 和 struct snd_soc_dai_ops, 然后调用snd_soc_register_dai向ASoC核心层注册, 例如atmel_ssc_dai.c.
针对Codec (codec_dai) : Codec厂商需要填充struct snd_soc_codec_driver(用于描述Codec内部工作逻辑)和struct snd_soc_dai_driver、struct snd_soc_dai_ops(用于描述AFIx), 然后调用snd_soc_register_codec向ASoC核心层注册, 例如wm9081.c.
针对Machine (codec): 电路板商需要填充struct snd_soc_dai_link、struct snd_soc_ops, 然后准备一个struct snd_soc_card把dai_link包裹起来, 然后调用snd_soc_register_card注册此snd_soc_card. 例如atmel_wm8904.c.

当底层调用了snd_soc_register_card时, ASoC核心层会从全局链表中找到dai_link指定的platform、cpu_dai、codec_dai、codec, 并建立一个struct snd_soc_pcm_runtime来保存这些对应关系. 然后核心层会snd_card_new创建声卡, snd_pcm_new创建pcm逻辑设备, 最后snd_card_register注册声卡. 此后, 用户空间就可以看到设备节点了. 当用户空间访问设备节点时, 最终由ASoC核心层响应, 核心层会通过snd_soc_pcm_runtime找到对应的platform、cpu_dai、codec_dai、codec, 并根据需要回调它们实现的接口函数.

ASoC架构流程图描述：

用户空间（User-space）
- 这一层由用户应用程序和ALSA的用户空间库（如 alsa-lib）组成，负责音频设备的控制。
- 用户空间通过ALSA提供的接口，控制音量、采样率、通道等。
- 通过调用 alsa-lib，用户空间发出音频播放或录制的请求，向内核空间传递数据。
用户空间组件：
- 应用程序（如音频播放器）
- ALSA 用户空间库（alsa-lib）
内核空间（Kernel-space）
- 这一层负责硬件驱动与系统之间的交互。ASoC的内核空间层包括多个子模块：
1. Machine Driver（机器驱动）
  - 机器驱动是ASoC架构的核心，它负责配置和管理音频硬件平台，包括平台设备的初始化。
  - 它负责设置平台的音频流向、硬件接口（I2S、PCM等）的连接。
2. Codec Driver（编解码器驱动）
  - 编解码器驱动与实际的音频编解码器（DAC、ADC）硬件进行通信。
  - 它处理音频数据的数字/模拟转换，音频格式配置（如采样率、比特宽度）等。
3. Platform Driver（平台驱动）
  - 平台驱动负责与底层硬件交互，控制音频数据的流向和数据路径（如DMA、I2S总线）。
  - 它通常是硬件特定的，管理音频总线、数据传输路径和硬件接口的配置。
4. Dai Driver（Dai驱动）
  - Dai驱动处理音频数据的接口，确保音频流通过I2S、PCM等接口正确传输。
  - 这里可以有多个Dai驱动，分别管理不同的音频输入输出接口。
音频数据传输与处理（Audio Data Path and Transmission）
- 音频数据流在硬件平台和编解码器之间进行传输，通常使用 DMA（Direct Memory Access）来提高数据传输的效率。
- 数据在各个音频组件之间流动，具体包括：
  - 从内存到编解码器（DAC / ADC）
  - 从编解码器到音频输出（例如扬声器）
- 平台驱动 和 Dai驱动 确保音频数据流通畅。
控制与配置（Control & Configuration）
- 通过ALSA控制接口（snd_ctl），用户空间可以调节音量、选择输入/输出通道、设置采样率等。
- 控制命令通过内核空间的驱动（Codec Driver、Machine Driver等）进行相应的配置。

ASoC架构的流程

[用户空间] ---> [ALSA 用户空间库] ---> [内核空间]
                (应用程序/命令)        (ASoC 驱动层)

[内核空间] 包含以下模块：
   |-- [Machine Driver]
   |-- [Codec Driver] <--> [编解码器硬件]
   |-- [Platform Driver] <--> [音频总线/硬件接口]
   |-- [Dai Driver] <--> [音频数据接口] (I2S, PCM)

[数据传输与处理] <--> [音频硬件]
(音频数据流：内存 <-> 编解码器 <-> 输出设备)

2.1、struct snd_soc_card

include/sound/soc.h

struct snd_soc_card {
	const char *name;
	const char *long_name;
	const char *driver_name;
	const char *components;
#ifdef CONFIG_DMI
	char dmi_longname[80];
#endif /* CONFIG_DMI */
	char topology_shortname[32];

	struct device *dev;
	struct snd_card *snd_card;
	struct module *owner;

	struct mutex mutex;
	struct mutex dapm_mutex;

	/* Mutex for PCM operations */
	struct mutex pcm_mutex;
	enum snd_soc_pcm_subclass pcm_subclass;

	int (*probe)(struct snd_soc_card *card);
	int (*late_probe)(struct snd_soc_card *card);
	void (*fixup_controls)(struct snd_soc_card *card);
	int (*remove)(struct snd_soc_card *card);

	/* the pre and post PM functions are used to do any PM work before and
	 * after the codec and DAI's do any PM work. */
	int (*suspend_pre)(struct snd_soc_card *card);
	int (*suspend_post)(struct snd_soc_card *card);
	int (*resume_pre)(struct snd_soc_card *card);
	int (*resume_post)(struct snd_soc_card *card);

	/* callbacks */
	int (*set_bias_level)(struct snd_soc_card *,
			      struct snd_soc_dapm_context *dapm,
			      enum snd_soc_bias_level level);
	int (*set_bias_level_post)(struct snd_soc_card *,
				   struct snd_soc_dapm_context *dapm,
				   enum snd_soc_bias_level level);

	int (*add_dai_link)(struct snd_soc_card *,
			    struct snd_soc_dai_link *link);
	void (*remove_dai_link)(struct snd_soc_card *,
			    struct snd_soc_dai_link *link);

	long pmdown_time;

	/* CPU <--> Codec DAI links  */
	struct snd_soc_dai_link *dai_link;  /* predefined links only */
	int num_links;  /* predefined links only */

	struct list_head rtd_list;
	int num_rtd;

	/* optional codec specific configuration */
	struct snd_soc_codec_conf *codec_conf;
	int num_configs;

	/*
	 * optional auxiliary devices such as amplifiers or codecs with DAI
	 * link unused
	 */
	struct snd_soc_aux_dev *aux_dev;
	int num_aux_devs;
	struct list_head aux_comp_list;

	const struct snd_kcontrol_new *controls;
	int num_controls;

	/*
	 * Card-specific routes and widgets.
	 * Note: of_dapm_xxx for Device Tree; Otherwise for driver build-in.
	 */
	const struct snd_soc_dapm_widget *dapm_widgets;
	int num_dapm_widgets;
	const struct snd_soc_dapm_route *dapm_routes;
	int num_dapm_routes;
	const struct snd_soc_dapm_widget *of_dapm_widgets;
	int num_of_dapm_widgets;
	const struct snd_soc_dapm_route *of_dapm_routes;
	int num_of_dapm_routes;

	/* lists of probed devices belonging to this card */
	struct list_head component_dev_list;
	struct list_head list;

	struct list_head widgets;
	struct list_head paths;
	struct list_head dapm_list;
	struct list_head dapm_dirty;

	/* attached dynamic objects */
	struct list_head dobj_list;

	/* Generic DAPM context for the card */
	struct snd_soc_dapm_context dapm;
	struct snd_soc_dapm_stats dapm_stats;
	struct snd_soc_dapm_update *update;

#ifdef CONFIG_DEBUG_FS
	struct dentry *debugfs_card_root;
#endif
#ifdef CONFIG_PM_SLEEP
	struct work_struct deferred_resume_work;
#endif
	u32 pop_time;

	/* bit field */
	unsigned int instantiated:1;
	unsigned int topology_shortname_created:1;
	unsigned int fully_routed:1;
	unsigned int disable_route_checks:1;
	unsigned int probed:1;
	unsigned int component_chaining:1;

	void *drvdata;
};

2.2、struct snd_card

struct snd_card可以说是整个ALSA音频驱动最顶层的一个结构，整个声卡的软件逻辑结构开始于该结构，几乎所有与声音相关的逻辑设备都是在snd_card的管理之下，声卡驱动的第一个动作通常就是创建一个snd_card结构体。

include/sound/core.h

struct snd_card {
	int number;			/* number of soundcard (index to
								snd_cards) */

	char id[16];			/* id string of this card */
	char driver[16];		/* driver name */
	char shortname[32];		/* short name of this soundcard */
	char longname[80];		/* name of this soundcard */
	char irq_descr[32];		/* Interrupt description */
	char mixername[80];		/* mixer name */
	char components[128];		/* card components delimited with
								space */
	struct module *module;		/* top-level module */

	void *private_data;		/* private data for soundcard */
	void (*private_free) (struct snd_card *card); /* callback for freeing of
								private data */
	struct list_head devices;	/* devices */

	struct device ctl_dev;		/* control device */
	unsigned int last_numid;	/* last used numeric ID */
	struct rw_semaphore controls_rwsem;	/* controls list lock */
	rwlock_t ctl_files_rwlock;	/* ctl_files list lock */
	int controls_count;		/* count of all controls */
	size_t user_ctl_alloc_size;	// current memory allocation by user controls.
	struct list_head controls;	/* all controls for this card */
	struct list_head ctl_files;	/* active control files */
#ifdef CONFIG_SND_CTL_FAST_LOOKUP
	struct xarray ctl_numids;	/* hash table for numids */
	struct xarray ctl_hash;		/* hash table for ctl id matching */
	bool ctl_hash_collision;	/* ctl_hash collision seen? */
#endif

	struct snd_info_entry *proc_root;	/* root for soundcard specific files */
	struct proc_dir_entry *proc_root_link;	/* number link to real id */

	struct list_head files_list;	/* all files associated to this card */
	struct snd_shutdown_f_ops *s_f_ops; /* file operations in the shutdown
								state */
	spinlock_t files_lock;		/* lock the files for this card */
	int shutdown;			/* this card is going down */
	struct completion *release_completion;
	struct device *dev;		/* device assigned to this card */
	struct device card_dev;		/* cardX object for sysfs */
	const struct attribute_group *dev_groups[4]; /* assigned sysfs attr */
	bool registered;		/* card_dev is registered? */
	bool managed;			/* managed via devres */
	bool releasing;			/* during card free process */
	int sync_irq;			/* assigned irq, used for PCM sync */
	wait_queue_head_t remove_sleep;

	size_t total_pcm_alloc_bytes;	/* total amount of allocated buffers */
	struct mutex memory_mutex;	/* protection for the above */
#ifdef CONFIG_SND_DEBUG
	struct dentry *debugfs_root;    /* debugfs root for card */
#endif

#ifdef CONFIG_PM
	unsigned int power_state;	/* power state */
	atomic_t power_ref;
	wait_queue_head_t power_sleep;
	wait_queue_head_t power_ref_sleep;
#endif

#if IS_ENABLED(CONFIG_SND_MIXER_OSS)
	struct snd_mixer_oss *mixer_oss;
	int mixer_oss_change_count;
#endif
};

struct list_head devices 记录该声卡下所有逻辑设备的链表
struct list_head controls 记录该声卡下所有的控制单元的链表
void *private_data 声卡的私有数据，可以在创建声卡时通过参数指定数据的大小

2.3、card注册

通常有两种方法注册一个card：

在machine驱动中注册一个名为 “soc-audio” 的 platform device，并将 struct snd_soc_card 结构变量作为这个device的私有数据，在 soc-core.c 调用名为 “soc-audio” 的 platform drv的probe函数，probe中调用 snd_soc_register_card 注册这个card.
直接在machine驱动中调用 snd_soc_register_card 函数注册card.

snd_soc_register_card流程如下：

上图中中：

1：绑定系统中相关的platform/cedec
2：声卡对象的创建
3：声卡注册
control：这是control相关的一些初始化函数

2.4、逻辑设备创建与注册

struct snd_device 隶属于card, 通常用来实现某一功能，一个逻辑设备一般来说会对应用户空间的一个或多个设备节点(也有某些仅在内核使用的逻辑设备不会创建设备节点)。

struct snd_device：

include/sound/core.h

struct snd_device {
	struct list_head list;		/* list of registered devices */
	struct snd_card *card;		/* card which holds this device */
	enum snd_device_state state;	/* state of the device */
	enum snd_device_type type;	/* device type */
	void *device_data;		/* device structure */
	const struct snd_device_ops *ops;	/* operations */
};

struct snd_device_ops

每个逻辑设备都有一个对应的snd_device_ops, 在新增一个逻辑设备时, 需要为此设备准备好该数据结构。

include/sound/core.h

struct snd_device_ops {
	int (*dev_free)(struct snd_device *dev);
	int (*dev_register)(struct snd_device *dev);
	int (*dev_disconnect)(struct snd_device *dev);
};

1.API

snd_device_new
该API用于创建一个逻辑设备，主要内容是分配一个struct snd_device空间, 初始化相关字段, 并把该逻辑设备添加到card->devices链表下。
snd_device_register
一般在注册声卡时(snd_card_register)会自动调用此处的API; 不过也可以在card注册完毕后, 在手动调用此API注册一个新的逻辑设备。、
snd_device_register_all
相当于对snd_device_register的封装: 针对card下的每一个逻辑设备, 调用__snd_device_register注册此逻辑设备。
snd_device_disconnect
一般在调用snd_card_disconnect时会调用此API.

2.字符设备驱动的创建

逻辑设备与用户空间是通过字符设备驱动交互的。一个逻辑设备可以创建一个或多个字符设备节点，节点创建的时机如下：

当声卡注册时（snd_card_register）, 会针对其下的每一个逻辑设备调用snd_device_register，后者会回调逻辑设备的回调函数（snd_device_ops->dev_register）。逻辑设备在实现dev_register时, 一般会调用snd_register_device, 后者会通过device_add创建一个设备节点. 所以调用几次snd_register_device, 就会存在几个设备节点。

所有ALSA字符设备的主设备号都是CONFIG_SND_MAJOR (116), ALSA系统在初始化时, 会在alsa_sound_init中调用register_chrdev，定义此类字符设备的统一处理函数snd_fops。snd_fops中只实现了snd_open函数, 当用户空间打开任一ALSA设备节点时, 都会进入到该open函数中。

在snd_open中, 会根据次设备号（每个逻辑设备都有自己的次设备号）, 选择对应的逻辑设备的ops函数, 然后替换file->f_op, 此后用户空间的任何操作都是直接与逻辑设备的ops函数交互的。ALSA系统中有一个全局数组snd_minors[], 数组的下标就是次设备号, 每个元素对应一个逻辑设备, snd_minor[i]-> f_ops存储的就是逻辑设备自己的ops函数.有了它, snd_open的实现就比较容易了, 只需用次设备号作为下标, 从snd_minors[]中找到对应的元素, 然后用元素的f_ops替换file->f_op即可。

3.逻辑设备中间层

在当前的系统中, 有很多逻辑设备中间层, 它们相当于对逻辑设备创建与注册中的步骤进行了封装, 然后对外提供了更加简洁的API来创建对应的逻辑设备。

设备类型	功能描述
Control 设备	管理音频硬件的控制接口，如音量、静音等控制。一般与音频流和配置相关。
PCM 设备	处理音频数据流（Playback 和 Capture）。包括音频的播放、录制等操作。
RAW/MIDI 设备	处理原始音频数据或 MIDI 数据，支持 MIDI 控制器和其他非音频数据流。
TIMER 设备	提供音频设备的定时功能，用于同步音频流的播放和录制。通常与采样率和时间控制相关。
JACK 设备	提供音频连接管理，支持与 JACK 音频服务器的交互，实现音频流的连接和断开。
Info 设备	提供设备的基本信息，如设备名称、版本、特性等，用于查询设备的详细信息。

除了Info设备外, 其它几个中间层都是对snd_device_new进行了一次封装. 当调用这些中间层提供的API时, 最终会在card下添加一个新的逻辑设备。

在card的注册阶段, 会扫描它下面的每一个逻辑设备, 然后调用snd_device_register来注册该逻辑设备. 当逻辑设备注册完成后, 核心层会回调snd_device_ops.dev_register函数, 如果dev_register里面调用了snd_register_device, 则会在用户空间出现字符设备节点.

重点介绍：PCM逻辑设备

PCM逻辑设备是以字符设备的形式呈现给用户空间；
内核实现了一个‘PCM中间层’, 该中间层对上向ALSA核心层注册, 将自己注册为一个逻辑设备, 并最终创建了字符设备节点, 负责与用户空间交互(snd_pcm_f_ops); 对下则提供API给底层驱动, 供底层驱动注册一个PCM设备.

从功能的角度来说, PCM逻辑设备的作用是供用户空间播放/录制PCM音频. PCM音频本质上来说就是一块Buffer, ‘PCM中间层’的作用就是从用户空间接收这块Buffer, 然后把Buffer的数据转给底层驱动播放. 底层驱动一般对应的是I2S控制器, 它收到数据后, 会通过I2S总线把数据传给codec, 然后codec经过DA转换后送到喇叭播放。

除了Buffer的传输, 还要解决配置的问题, 也就是配置I2S控制器和Codec芯片, 告诉它们应该按照什么样的clock、采样深度、通道数等来播放Buffer中的数据. 因此‘PCM中间层’也提供了一些ioctl给用户空间, 供它们设置这些参数。

从分工的角度来说, PCM中间层和底层驱动各自应该专注于哪些事情?

PCM中间层主要完成一些公共性的事情, 这些事情一般与具体的硬件无关（例如存储音频数据时, 肯定需要一个Buffer, 这个Buffer很显然用环形缓冲区描述比较好, 怎么管理这个环形缓冲区的读写指针? 另外, 用户空间设置的音频参数要检查其合法性. 还有, 用户空间可能启停音频播放/录制, 这意味着我们最好实现一个状态机, 来管理用户空间的切换操作. 等等）. 对于与具体硬件相关的操作, PCM中间层会pass给底层驱动去处理（这就意味着PCM中间层要定义interface, 让底层驱动去实现这些interface）。

底层驱动则处理与具体硬件相关的事情, 例如I2S控制器的配置, Codec芯片的配置, 时钟的初始化等等。