📚 课程目录第2章 Linux音频子系统架构

Linux音频子系统架构：从用户空间到硬件

做音频驱动开发，第一件事就是搞懂整个音频软件栈长什么样。我见过不少新手，上来就对着datasheet写寄存器，结果连声音从App到Codec芯片的路径都说不清楚。嗯，今天我们就来拆解这个路径。

ALSA，全称是Advanced Linux Sound Architecture。说白了，它就是Linux内核里负责音频的那一套框架。你想想看，用户空间的播放器、录音软件，怎么跟底层的I2S、Codec打交道？全靠ALSA在中间搭桥。

我个人习惯把ALSA分成三层：

我在项目中遇到过最典型的坑是：用户空间配置的采样率跟硬件实际跑的采样率不一致，结果声音变调。后来发现是ALSA core里的参数协商没走对。

核心要点：ALSA不是一块铁板，它是分层的。每一层只关心自己的事，上层不直接操作硬件寄存器。

应用程序怎么跟内核驱动说话？答案是ioctl系统调用。ALSA在/dev/snd/目录下创建了一堆设备节点：

应用程序打开/dev/snd/pcmC0D0p，然后通过ioctl发命令。比如设置采样率、声道数、格式，或者启动/停止数据流。内核里的ALSA core收到这些命令后，再往下派发给具体的驱动。

这里有个关键点：数据流不走ioctl。PCM数据是通过mmap或者read/write系统调用传递的。ioctl只负责控制，不负责搬数据。我曾经调试过一个案子，播放声音断断续续，查了半天发现是mmap缓冲区大小没对齐，导致内核和用户空间的数据同步出了问题。

调试小技巧：用strace抓一下播放器的系统调用，你能清楚看到它打开了哪个设备节点，发了哪些ioctl命令。这是定位用户空间问题的第一招。

ALSA虽然好用，但直接用它写嵌入式音频驱动还是太累。于是内核社区搞了ASoC——ALSA System on Chip。ASoC把音频驱动拆成三个角色：

为什么要分这么细？你想想看，同一个Codec芯片可以用在不同CPU上，同一个CPU也可以接不同Codec。如果所有代码揉在一起，每次换硬件都得重写驱动。ASoC这种分层设计，说白了就是为了复用。

我记得有一次做项目，CPU换了一颗，但Codec没变。我只需要重新写一个Machine驱动，Platform和Codec驱动直接复用。嗯，省了不少事。

注意：Machine驱动不是必须的。如果你的板子很简单，可以在设备树里直接描述Codec和Platform的连接关系，内核会自动创建一个虚拟的Machine驱动。但复杂场景下，还是老老实实写一个Machine驱动比较稳。

搞懂ASoC，得先认识几个关键结构体。它们就像乐高积木，拼在一起就是一套完整的音频驱动。

结构体	所属层	作用
`snd_soc_codec`	Codec	代表一个音频编解码芯片
`snd_soc_dai`	Codec / Platform	代表一个数字音频接口（I2S、PCM等）
`snd_soc_platform`	Platform	代表CPU侧的DMA引擎
`snd_soc_card`	Machine	代表整个声卡，把Codec和Platform串起来
`snd_soc_dai_link`	Machine	描述一个DAI连接，比如Codec的DAI连到Platform的哪个DAI

这些结构体在驱动初始化时会被注册到ASoC core里。core会帮你做很多脏活累活，比如PCM设备的创建、参数协商、DMA缓冲区管理。你只需要告诉core：我的Codec支持哪些采样率、我的Platform有几条DMA通道。

一句话总结：写ASoC驱动，本质就是填充这些结构体，然后注册到内核里。剩下的交给框架。

下面这张图是我画的一个ASoC分层架构，帮你直观理解三个角色怎么配合。

搞清楚了分层，我们再看看数据到底怎么流。假设你在手机上播放一首歌：

这个链路里，任何一个环节出问题，声音就出不来。我调试过最头疼的一个问题是：DMA已经搬了数据，I2S波形也对，但Codec就是不出声。后来发现是Codec的寄存器没配好，输出通路被静音了。嗯，这种问题查起来特别费时间。

调试建议：从后往前查。先确认Codec寄存器配置对不对，再看I2S波形，最后看DMA有没有搬数据。这样能快速定位问题在哪一层。

这一章我们聊了ALSA框架的整体结构、用户空间和内核空间的交互方式，以及ASoC的分层设计。说白了，音频驱动开发就是跟这三层打交道：用户空间配参数、内核core做调度、底层驱动操作硬件。搞懂这个框架，后面写I2S驱动、调PCM数据流，你才知道自己在干什么。