3. Linux ALSA 基础：ALSA 框架概述、PCM 设备与控制设备、asound.conf 与 .asoundrc

好，咱们进入正题。这一章我打算把 ALSA 的底裤扒开给你看。很多做车载音频的兄弟，调了几年路由，遇到问题还是只会 aplay -l 和 amixer 三板斧。说实话，这不够。你得理解 ALSA 到底是怎么组织音频设备的，PCM 设备和 Control 设备有什么区别，配置文件又是怎么生效的。

我个人习惯，学一个新框架先看它的骨架。ALSA 的骨架就三块：设备模型、用户空间接口、配置文件体系。咱们一个一个来。

3.1 ALSA 框架概述：从内核到用户空间

ALSA 全称是 Advanced Linux Sound Architecture。说白了，它就是 Linux 下音频的「交通管理局」。应用层想放音乐，内核层要操作硬件，中间全靠 ALSA 调度。

它的层级关系我画了张图，你先看一眼：

你看，从上到下四层。应用层调用 snd_pcm_open()，经过 libasound 库，再通过内核驱动访问硬件。我在项目中遇到过不少同事，直接在应用层用 ioctl 操作内核设备节点，结果绕过了 libasound 的插件机制，路由死活不通。嗯，这里要注意：车载音频路由的灵活性，全靠 libasound 层的插件链，别自己绕过去。

3.2 PCM 设备与控制设备

这两个概念容易混淆。我刚开始学 ALSA 时也搞混过，以为它们是一回事。其实分工很明确：

举个例子。你在车载系统中播放导航语音，PCM 设备负责把音频数据从内存搬到 I2S 总线，送给 Codec 芯片。而Control 设备负责告诉 Codec：「主音量调到 80%，左声道 mute 掉，路由选择 Line-In 通道」。两者缺一不可。

3.3 PCM 设备的命名规则

你执行 aplay -l 会看到类似这样的输出：

**** List of PLAYBACK Hardware Devices ****
card 0: rockchiprk3308 [rockchip-rk3308], device 0: dailink-multicodecs multicodecs-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: rockchiprk3308 [rockchip-rk3308], device 1: dailink-multicodecs multicodecs-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0

命名规则其实很简单：hw:Card,Device,Subdevice。比如 hw:0,0,0 就是 card 0、device 0、subdevice 0。但在车载系统中，我建议你不要直接用 hw 设备。为什么？因为 hw 设备没有采样率转换、没有通道重映射、没有软件混音。你直接往 hw:0,0 写数据，格式不对就报错，路由也不灵活。

我个人习惯，在车载项目中都用 plug 插件或者 dmix 插件包装一层。后面讲 asound.conf 时会细说。

3.4 asound.conf 与 .asoundrc

这两个文件是 ALSA 用户空间配置的核心。区别就一句话：asound.conf 是系统级，.asoundrc 是用户级。

• asound.conf：放在 /etc/ 目录下，影响所有用户。车载系统一般只改这个文件。
• .asoundrc：放在用户家目录 ~/.asoundrc，只影响当前用户。调试时临时用用可以，量产车机别用。

文件内容采用 ALSA 自定义的配置语法。我直接给你看一个车载项目中常用的配置片段：

# /etc/asound.conf
# 定义一个 PCM 设备，名为 "navi_output"
pcm.navi_output {
    type route
    slave.pcm {
        type dmix
        ipc_key 1234
        slave {
            pcm "hw:0,0"
            format S16_LE
            rate 48000
            channels 2
        }
    }
    ttable.0.0 1.0   # 左声道映射到左声道
    ttable.1.1 1.0   # 右声道映射到右声道
}

# 定义一个 Control 设备，用于音量控制
ctl.navi_volume {
    type hw
    card 0
}

这个配置做了什么事？它创建了一个名为 navi_output 的 PCM 虚拟设备。应用层只要打开 navi_output，数据就会经过 route 插件做通道映射，再经过 dmix 插件做软件混音，最后送到硬件 hw:0,0。你想想看，如果没有这层配置，应用层直接操作硬件，多路音频同时播放时就会打架。

3.5 配置文件的加载顺序与调试

ALSA 加载配置文件的顺序是这样的：

1. 首先读取 /etc/asound.conf（如果存在）
2. 然后读取 ~/.asoundrc（如果存在）
3. 如果都没有，使用 ALSA 内置的默认配置

注意：后加载的配置会覆盖先加载的。所以如果你在 ~/.asoundrc 里定义了一个和 asound.conf 同名的 PCM 设备，用户级配置会生效。这在调试时很有用，但量产时一定要清理干净。

调试配置文件时，我常用的命令是：

# 检查配置是否被正确解析
alsactl -f /etc/asound.conf init

# 列出所有 PCM 设备（包括虚拟设备）
aplay -L

# 测试自定义 PCM 设备
speaker-test -D navi_output -c 2 -t sine

# 查看 Control 设备列表
amixer -c 0 controls

有一次我在调试一个车载项目，aplay -L 死活看不到我定义的虚拟设备。折腾了半天，发现是 asound.conf 里有个语法错误——少写了一个大括号。ALSA 解析失败后直接用了默认配置，没有任何报错。嗯，这里要提醒你：ALSA 配置解析失败时不会打印错误信息，你得自己用 alsactl init 验证。

3.6 实战：快速搭建一个车载音频路由测试环境

假设你手头有一块 RK3308 的开发板，Codec 是 ES8316。你想验证导航语音和媒体音乐能不能同时播放，并且各自独立控制音量。可以这样配：

# /etc/asound.conf

# 导航语音输出
pcm.navi {
    type route
    slave.pcm {
        type dmix
        ipc_key 2048
        slave {
            pcm "hw:0,0"
            format S16_LE
            rate 48000
            channels 2
        }
    }
    ttable.0.0 1.0
    ttable.1.1 1.0
}

# 媒体音乐输出
pcm.media {
    type route
    slave.pcm {
        type dmix
        ipc_key 4096
        slave {
            pcm "hw:0,0"
            format S16_LE
            rate 48000
            channels 2
        }
    }
    ttable.0.0 0.8   # 媒体音量默认 80%
    ttable.1.1 0.8
}

# 默认设备指向 media
pcm.!default {
    type copy
    slave.pcm "media"
}

然后开两个终端：

# 终端1：播放导航语音
speaker-test -D navi -c 2 -t sine -f 1000 -l 1

# 终端2：播放媒体音乐
speaker-test -D media -c 2 -t sine -f 440 -l 0

你会听到两个声音同时输出，而且导航语音的音量是 100%，媒体音乐是 80%。这就是 ALSA 配置文件的威力——不需要改一行应用代码，就能实现音频路由和混音策略。