做Linux下的音频项目，无论是桌面应用放个提示音、给嵌入式板子接麦克风阵列，还是搞一套低延迟的音频处理链，最终都会撞上同一个名字：ALSA。老实讲，我最早接触ALSA时是有点懵的，网上各种配置片段拷贝来拷贝去，“device or resource busy”“snd_pcm_hw_params error”这类报错几乎成了家常便饭。后来把音频基础里的采样率、位深、缓冲机制弄明白，再回头去看ALSA框架，才发现那堆接口和报错其实是很有逻辑的一整套东西。这篇文章就按这个顺序走一遍：先补数字音频的几个基本概念，再拆解ALSA的总体结构，接着实际跑一个PCM播放/录音的最小程序，最后聊聊配置文件、排错和延迟调试。无论你是刚准备入门，还是已经在Linux音频里折腾了一段时间，应该都能找到对自己有用的部分。

1. 从声波到 PCM：先把数字音频的底子补齐

1.1 采样率、位深、声道：数字音频的三个基本维度

数字音频说白了就是把连续的声波每隔一段时间量一次振幅。采样率负责“每隔多久量一次”，位深负责“把振幅量化得有多细”，声道负责“同时采样几路信号”。三者一组合，就决定了声音文件的大小，也决定了系统处理声音时消耗的资源。

采样率的设定背后是奈奎斯特采样定理：要从离散采样点还原出原始波形，采样率至少要达到最高频率的两倍。人耳能感知的频率上限通常在20kHz左右，所以CD选择了44.1kHz，留出一点点余量。视频行业习惯用48kHz，因为它和24fps、30fps的帧率能对上整数倍时钟，数码设备传输时不易产生频率偏差。这个差异看起来不起眼，后面在ALSA里设置rate的时候，经常就是因为设了一个硬件不支持的采样率导致报错。

位深决定了每个采样点的动态范围。16bit的理论动态范围约6.02×16+1.76≈98dB，24bit算出来超过144dB，但实际设备能到120dB已经很出色。打个不太严谨的比方：16bit像是用65536级台阶去描述音量，24bit则是1677万级，台阶越细，弱音部分的失真越小。ALSA里常见的格式有S16_LE、S24_LE、S32_LE，浮点格式在DSP处理和音频插件之间也很常用，因为它们做数学运算时不容易溢出。

声道数影响的是每帧的大小。帧（frame）是ALSA里最基础的时间单位，它表示“某一瞬间所有声道的一组采样”。双声道16bit的情况下，一帧就是2×(16/8)=4字节；如果是4声道24bit，一帧是4×3=12字节。所有的API参数、Buffer大小都用帧来描述，所以这个单位一定要先建立起来。举个例子，44.1kHz立体声16bit的裸数据速率是44100×4≈176400字节每秒，一首5分钟的WAV大概就是52MB，这也是为什么音频缓存不能随手开成几十MB——内存占用和延迟都会迅速上升。

1.2 周期与缓冲区：延迟和吞吐怎么平衡

ALSA播放过程中有period（周期）和buffer（缓冲区）两个关键参数。你可以把buffer理解为声卡和用户程序之间的环形水库，period则是这个水库被划分成的多个小水桶。声卡每消耗完一个period，就会产生一次中断，调用一次用户空间的读写逻辑；中断频率越高，应用程序对数据交接的响应越快，延迟也就越低，但系统开销增大，反而容易造成丢数据。

延迟最粗略的估算方法是buffer_size÷sample_rate。比如48kHz采样率下，buffer 1024帧的延迟约21.3毫秒，听起来可能不多，但在乐器演奏类应用里完全不可接受；如果压到128帧，就只有约2.7毫秒。代价是，如果CPU调度稍微抖动一下，或者系统负载一高，缓冲来不及填满，声卡就会报underrun（播放时没数据）或overrun（录音时数据来不及读），也就是常见的xrun。xrun是ALSA调试里最熟悉的老朋友，后面会专门展开。

2. ALSA 框架总体拆解：一条声音数据的完整通路

2.1 从 OSS 到 ALSA：内核与用户态是怎么分工的

Linux早期用的是OSS，接口简单但在多声道、多声卡、硬件抽象上很不灵活。ALSA从2.6内核开始成为默认音频框架，它把工作分成三层：内核里的声卡驱动负责和硬件打交道、处理中断和DMA；用户空间的alsa-lib提供API，比如我们常用的snd_pcm_open、snd_pcm_writei；alsa-utils则是调试工具，aplay、arecord、amixer、speaker-test都来自它。绝大多数人写应用时只跟alsa-lib打交道，并不需要直接碰内核API。但是当你遇到某些内核驱动的bug，或者想排查DMA中断行为时，还是要能看懂dmesg里snd相关模块的日志。

这里有一个很容易被忽略的点：alsa-lib并不是内核ALSA驱动的简单封装，它在用户态做了大量工作，包括插件机制、软件混音、格式转换。也就是说，即使硬件没有变化，只要alsa-lib的配置不同，同一个“default”设备的行为也可能完全不同。这也是为什么同样的程序在这台机器上跑得好好的，换到另一台就出各种怪问题。

2.2 看一眼 /dev/snd 和 /proc/asound

打开终端执行ls /dev/snd，会看到controlC0、pcmC0D0p、pcmC0D0c这一堆节点。C0表示声卡0，D0表示该声卡上的第0个PCM设备，p/c后缀代表playback还是capture。比如pcmC0D0p是声卡0的playback设备，录音通常用pcmC0D0c。这些字符设备就是用户态访问内核驱动的入口。

相比/dev/snd，我更建议遇到问题先看/proc/asound。cat /proc/asound/cards可以看到识别到的声卡和编号，cat /proc/asound/pcm能看到每个PCM设备的格式和状态，cat /proc/asound/card0/pcm0p/sub0/status能看到当前运行状态、时钟位置、以及是否发生过xrun。这些信息比对着API猜要直观得多。曾经有个项目里录音总是莫名其妙少几帧，最后就是从这个status文件里看到持续出现overrun，才定位到是驱动DMA传输的FIFO太小，和下层硬件缓冲的匹配问题，跟业务代码完全无关。

2.3 设备命名与插件：hw、plughw 和 default 不是一回事

ALSA用字符串标识符选择设备，最常见的三个：hw:0,0指直接访问声卡0设备0，不做任何格式转换，也不经过混音器；plughw:0,0则会在设备之上套一层plug插件，自动完成采样率、格式、声道的转换；default通常不是真实硬件，而是系统配置文件定义出来的一个复合PCM，一般会带上dmix、plug等插件。

这三者的区别在实际使用中特别容易踩坑。你用aplay -D hw:0,0 test.wav放一个96kHz的文件，很可能报hw params错误，因为很多板载声卡硬件只支持48kHz。此时换成plughw:0,0就能出声音，因为plug会做重采样和格式转换。当然，转换意味着CPU开销和精度损失，正式项目里如果是固定硬件，尽量在应用层就把数据格式配置好，不要依赖plug兜底。

3. 动手写第一个 ALSA 播放程序

3.1 最小播放器的骨架

第一个程序不要追求功能完整，能跑通最重要。核心是用snd_pcm_open打开设备，设置硬件参数，然后循环写入PCM数据。下面这段代码用标准ALSA接口生成一个440Hz正弦波并直接播放：

#include <alsa/asoundlib.h> #include <math.h> #include <stdlib.h> #include <stdio.h> #define SAMPLE_RATE 44100 #define CHANNELS 2 #define FORMAT SND_PCM_FORMAT_S16_LE int main(void) { snd_pcm_t *pcm; snd_pcm_hw_params_t *params; snd_pcm_uframes_t period_size = 256; int ret; ret = snd_pcm_open(&pcm, "default", SND_PCM_STREAM_PLAYBACK, 0); if (ret < 0) { fprintf(stderr, "open error: %s\n", snd_strerror(ret)); return -1; } snd_pcm_hw_params_malloc(&params); snd_pcm_hw_params_any(pcm, params); snd_pcm_hw_params_set_access(pcm, params, SND_PCM_ACCESS_RW_INTERLEAVED); snd_pcm_hw_params_set_format(pcm, params, FORMAT); snd_pcm_hw_params_set_channels(pcm, params, CHANNELS); unsigned int rate = SAMPLE_RATE; snd_pcm_hw_params_set_rate_near(pcm, params, &rate, 0); snd_pcm_hw_params_set_period_size_near(pcm, params, &period_size, 0); ret = snd_pcm_hw_params(pcm, params); if (ret < 0) { fprintf(stderr, "hw params error: %s\n", snd_strerror(ret)); return -1; } snd_pcm_hw_params_free(params); short *buf = malloc(period_size * CHANNELS * sizeof(short)); for (int i = 0; i < period_size; i++) { short v = (short)(30000 * sin(2.0 * M_PI * 440 * i / SAMPLE_RATE)); buf[2 * i] = v; buf[2 * i + 1] = v; } for (int j = 0; j < 200; j++) { ret = snd_pcm_writei(pcm, buf, period_size); if (ret == -EPIPE) { fprintf(stderr, "underrun, recovering\n"); snd_pcm_prepare(pcm); } else if (ret < 0) { fprintf(stderr, "write error: %s\n", snd_strerror(ret)); break; } } snd_pcm_drain(pcm); snd_pcm_close(pcm); free(buf); return 0; }

编译时链接ALSA库和数学库：gcc -o demo demo.c -lasound -lm。这段代码能让你第一次听到从你自己程序里输出的440Hz正弦波。要注意几个点：snd_pcm_hw_params_any先用设备当前配置填满params，然后逐个覆盖这里关心的参数；如果硬件不支持某个值，未必会立即报错，而是在snd_pcm_hw_params应用配置时才失败。真正的工程代码里需要检查每一步的返回值，并且用*_near系列做参数协商。

3.2 参数协商过程为什么重要

很多新手问：为什么不能直接跟声卡说“我要44100/16bit/双声道”？因为硬件的能力是有限的，不是所有声卡都支持所有格式。有的只支持48kHz，有的通道数上限是2，还有的DMA周期有硬件下限。ALSA的设计哲学是协商：应用提出期望值，硬件返回实际支持值。用snd_pcm_hw_params_set_rate_near设置采样率后，rate变量会被改写为硬件实际支持的数值，代码需要拿这个被改写后的值重新计算数据生成、缓冲大小、延迟时间等。

硬编码假设是大忌。一台硬件上默认44100能正常播放，换到另一台48kHz的声卡上，如果代码里还按44100生成正弦波，播放出来的音高就会偏。更隐蔽的问题是buffer和period的真实大小也要查出来，不能拿申请值去算延迟。读取推荐用snd_pcm_get_params：

snd_pcm_uframes_t buffer_size, period_size; snd_pcm_get_params(pcm, &buffer_size, &period_size);

拿到实际值后，再根据结果计算填充数据，这才是稳妥做法。

3.3 录音与双工：不只是把 writei 换成 readi

录音的逻辑跟播放几乎对称：流类型改成SND_PCM_STREAM_CAPTURE，用snd_pcm_readi读数据。但坑通常不在API，而在权限和设备布局：通常用户需要属于audio组，否则打不开capture设备；很多板子上声音输入可能有多个源，得靠alsamixer的Capture通道选择和硬件增益设置才能录到正确的信号。

比较头疼的是同时播放和录音的双工场景。如果应用希望边录边放，比如数字对讲机、实时变声器，就需要打开两个PCM句柄，或者选择硬件上支持全双工的声卡设备。另一个容易忽略的点是capture和playback之间的时钟偏移：两个独立句柄各自跑各自的时钟，长时间采集后回放的数据会和输入逐渐漂移。工程做法是定期检查缓冲水位，通过丢弃或补零来校准延迟。这个问题在语音实时通话项目里几乎必现，最好在设计阶段就留出调整接口。

3.4 状态机与 xrun 恢复

ALSA的PCM内部有明确的状态机，常见状态包括open、setup、prepared、running、xrun、suspended。writei返回-EPIPE表示underrun，说明声卡已经把buffer消耗空了，应用没能及时填充；readi返回-EPIPE对应overrun，说明录音缓冲区满了，应用没来得及读走。恢复的标准动作是调用snd_pcm_prepare后再继续读写。

更精细的控制可以用sw_params设置启动阈值。比如希望缓冲区的数据达到一半再开始播放，避免一开头就underrun，可以这样：

snd_pcm_sw_params_t *sw; snd_pcm_sw_params_malloc(&sw); snd_pcm_sw_params_current(pcm, sw); snd_pcm_sw_params_set_start_threshold(pcm, sw, buffer_size / 2); snd_pcm_sw_params(pcm, sw); snd_pcm_sw_params_free(sw);

这个阈值直接影响起播延迟和稳定性，是需要反复调的经验值。

4. 配置文件与多应用共存：asound.conf 的正确姿势

4.1 配置文件的解析顺序和基本结构

ALSA的配置文件是文本格式，约定优先读取$HOME/.asoundrc，然后是/etc/asound.conf。如果做嵌入式裁剪，也可能没有这两个文件，此时所有设备直接按内核里的默认值处理。文件语法既支持简单的card块，也支持嵌套PCM定义。因为配置语法坑很多，我的建议是能不写就别写，一旦要写就用最直接的复制结构，避免乱加可能引入反作用的设置。

4.2 一个几乎不会出错的 dmix 配置

最常见的需求是让两个应用同时发声。直接hw:0,0时，一个应用打开设备后其他应用再打开就会得到“device or resource busy”。ALSA为此提供了dmix插件，它负责把多个应用的PCM流混音后送到硬件。下面这个配置，可以让默认设备指向一个dmix实例：

pcm.dmix1 { type dmix ipc_key 2048 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 8192 } } pcm.!default { type plug slave.pcm "dmix1" }

ipc_key随便用一个足够大的数字，用于区分不同应用共享的混音通道。外部应用写入default时，数据经过plug转换格式后进入dmix1，dmix1周期性把混好的数据交给硬件的hw:0,0。这样出来的延迟会比直连hw略高，但换来的是多应用共存。如果系统上层已经跑了PipeWire或PulseAudio，它们内部已经有自己的混音层，一般不需要再在ALSA层配dmix，否则相当于两层混音，延迟翻倍。

4.3 plug 与权限管理一样不能少

除了dmix，plug是最常用的插件，它负责通道数、格式、采样率的自动转换。什么场景需要它？典型是播放器源码里期望96kHz，而声卡只支持48kHz；或者录音应用想采24bit，但驱动只给16bit。plug都会在用户空间完成转换。但注意，自动转换有CPU和延迟代价，如果你的应用对延迟极其敏感，就不要走default这个复合设备，而是直接用硬件hw并把所有参数都协商好。

权限问题再唠叨一句：ALSA的control和PCM设备通常属于audio组，权限不对时即使root能打开，普通用户也打不开。嵌入式系统里如果追求最小权限，需要把用户加进audio组，或者配置好相关设备访问规则。调声卡没有声音时，先确认权限，再怀疑配置。

5. 调试、排查与性能优化实录

5.1 排查问题的标准顺序

遇到音频问题，我的固定顺序是：先看硬件层，再查应用层，最后才动配置。第一步，aplay -l、arecord -l确认驱动识别了哪些声卡；cat /proc/asound/cards看看默认声卡顺序，多块USB声卡插入顺序颠倒很常见，这会导致程序打开的设备不是你想要的。第二步，lsof /dev/snd/*看是不是有别的进程占用了设备，排查device busy非常直接。第三步，用speaker-test -D hw:0,0 -c 2 -t wav -l 1做一个最小验证，如果这个都放不出来，问题就在驱动、声道或静音设置上。

很多“没声音”问题最后都出在mixer上，而不是API。ALSA的Mixer接口和PCM接口是分开的，PCM播放正常不等于你能听到声音，因为硬件输出可能被静音了或者主音量是0。拿到一块新板子第一件事就是跑alsamixer，把Master、PCM、SPK以及带Auto-Mute的开关全部过一遍，这个习惯能省掉一大半的困扰。

5.2 高频报错速查表

5.3 低延迟调试的具体实验记录

低延迟这件事，说到底是和水位做斗争。在一个音频采集回放项目里，我用USB音频接口做测试，平台是某arm开发板。开始时用2048帧的buffer和512帧的period，播放48kHz的提示音，延迟明显到用耳朵都能听出回声感。接着按2048→1024→512→256→128的顺序压period尺寸，每一档都用aplay直接测试：

aplay -D hw:0,0 --period-size=256 --buffer-size=512 sine48k.wav

到128帧period时，偶尔会听到爆音，dmesg里出现类似snd_xxx: XRUN的日志。后来查下来，问题不在ALSA配置，而是开发板CPU的调度器把音频进程降了优先级，同时DMA中断线程被其他高负载任务延迟。解决办法是给音频线程设定更高的实时优先级，关闭CPU频率调频，以及把音频进程绑定到一个专用核上。这一轮下来，延迟降到大约2到3毫秒才算稳定。

有一个经验值得分享：不要一开始就在library层做各种小技巧，先把系统负载跑起来、把开关机、录音这些并发场景考虑进去。纯空闲状态下很好调的两毫秒，在实际业务并发时往往立刻破功。所以测试低延迟配置时，必须模拟真实运行条件。另外，如果项目里允许，最好做个物理loopback测量：把输出接回输入，播放一个冲击信号，在录音文件里找到冲击点，两者的时间差就是路径延迟，这个值包含应用内部buffer、ALSA驱动和声卡硬件FIFO的累计延迟。没有这个基准值，谈低延迟优化都像在盲调。

6. 最后分享几条实践心得

玩ALSA这些年，我最大的体会是：先有音频基础概念，再碰框架，顺序对了很多问题都能自己想明白。如果只是到处复制asoundrc，今天调好了明天换块声卡又崩。建议新拿到一块板子时，先花十分钟看aplay -l、cat /proc/asound/cards，再用alsamixer把所有可能的静音开关过一遍，最后才轮到写代码。很多“没声音”问题最后都出在mixer和默认设备上，而不是API。

在一个真实产品里，我最后都会让应用避开default等太过抽象的插件设备，而是直接定义自己的PCM别名，比如pcm.myplay { type dmix; ... }，这样既受控又有兜底，后面调试也清楚。项目里也会固定一套统一的debug打点，把每次open的设备名、请求的采样率、实际协商到的buffer/period都打出来，以后线上问题基本靠日志就能定位到是驱动、配置还是应用的问题。

自己现在遇到ALSA报错，第一反应已经不再是怎么复制一条配置把报错压下去，而是先从机制上想一遍：采样率为什么协商、period为什么存在、buffer为什么有水位。想清楚这几件事，绝大多数音频问题都能在几分钟内推出一个靠谱的排查方向。最后分享一个伴随了我很多项目的小习惯：工程里永远不要用裸的default，而是定义成pcm.myplay这类带明确含义的别名；每次open时把设备名、请求参数、实际协商参数打点记录下来。这个习惯帮我省下了大量的排查时间，也希望你在下一个音频项目里直接用起来。