说起ALSA很多刚接触嵌入式Linux开发的人第一反应都是头皮发麻。我最初在一台只有命令行环境的Linux设备上需要同时实现录音和播放功能面对一堆以snd_pcm_开头的API函数和网上零零散散的教程差不多折腾了两个通宵才把整个流程跑通。后来我把这段经历系统的整理成了一篇菜鸟修炼笔记沿着音频数据从麦克风到扬声器的完整路径把ALSA录制和播放的详细过程一步步拆开。这篇文章就是那份笔记的完整版适合刚入门Linux音频开发、被ALSA接口绕晕的开发者也适合需要在嵌入式设备上快速实现音频功能的同学参考。我不会堆API文档只会说清楚每一行代码背后的逻辑以及实际调试时最常踩的那些坑。1. 声音在Linux里的流动路径先把概念装进脑子很多菜鸟直接上手找snd_pcm_writei的用法结果完全不理解参数和数据格式最后代码能编译跑起来却是噪音或者干脆无声。我建议先花半小时把音频数据的整个流动路径搞清楚后面写代码会顺畅得多。1.1 整个音频链路声波如何变成你能操作的数据声音的原始形式是模拟信号也就是麦克风膜片震动产生的连续电压变化。要让计算机能处理必须经过采样和量化将连续的波形变成一个个离散的数字点这就是PCMPulse Code Modulation数据。在Linux系统里这个转换由声卡上的ADC模数转换器完成。转换后的数字PCM数据会经由内核里的ALSA驱动送入缓冲区用户态程序通过ALSA库提供的API从缓冲区里把这些数据读出来就完成了录音反过来应用把PCM数据写入缓冲区驱动再送入声卡的DAC数模转换器还原成模拟信号经过功放推动扬声器就完成了播放。整个链路里ALSA分成两部分内核中的音频驱动框架以及用户态的libasound库。我们平时调用的snd_pcm_*系列函数都是libasound库提供的封装接口。它们的底层通过ioctl和内核驱动通信但对于应用开发者来说完全不用关心驱动层的实现只需要理解PCM设备句柄这个抽象概念——打开一个PCM设备然后往里面读写数据就行。1.2 PCM、帧、周期API文档里那些词到底什么意思ALSA的文档对新手极不友好满屏都是PCM、frame、period这些术语。但如果你搞不懂这些词后面写代码就是瞎子摸象。采样率rate每秒钟采样的次数单位Hz。常见的有8000电话音质、16000语音识别常用、44100CD音质、48000视频行业标准。位深format每个采样点用多少bit表示最常用的是16bit也就是SND_PCM_FORMAT_S16_LELE表示小端字节序。声道数channels单声道是1立体声是2。帧frame一次采样中所有声道数据的集合。比如双声道16bit格式下一帧就是4字节左声道和右声道各2字节。帧是ALSA读写操作的基本单位。周期period一次中断或者一次批量传输所包含的帧数。可以理解成内核把数据切成一块一块的每攒够一个period就通知应用来取一次。period设小了延迟低但CPU开销大设大了CPU开销小但延迟明显。缓冲区buffer内部环形缓冲区能容纳的总帧数。一个buffer通常被分成若干个period。举个例子双声道、16bit、44100Hz的PCM流一帧是2声道数×2字节4字节一秒钟的数据量就是44100×4176400字节。如果你要播放5秒需要准备约882000字节的数据。这个计算在后面分配内存、判断数据量时非常常用。2. 环境与设备勘察装库、看卡、挑设备名开始写代码之前先把开发环境和目标设备摸清楚。这一步花不了多少时间但能避免你后面把大量时间浪费在设备不存在或者参数不支持这类低级问题上。2.1 安装ALSA开发库与命令行工具在大多数Debian/Ubuntu系统上只需要安装两个包libasound2-dev提供开发用的头文件和库文件alsa-utils提供aplay、arecord、amixer等命令行工具。sudo apt update sudo apt install libasound2-dev alsa-utils如果是嵌入式平台一般开发包里已经包含了ALSA库直接看/usr/include/alsa/asoundlib.h是否存在即可。交叉编译时记得把include路径和库路径指对编译命令大致是gcc -o alsa_test alsa_test.c -lasound-lasound就是链接libasound库。这一步如果报找不到头文件或者libasound.so优先检查是不是没装libasound2-dev。2.2 摸清设备aplay、arecord与proc文件系统在写代码前先用命令行工具验证设备本身的录放功能是正常的。这个经验非常重要——先用命令确认硬件没问题再怀疑自己的代码。查看系统有哪些声卡用cat /proc/asound/cards看播放设备aplay -l看录音设备arecord -l测试播放aplay -d 5 test.wav测试录音arecord -d 5 -f cd test.wav跑完再用aplay test.wav放出来听一下。如果命令行直接失败说明板子的音频驱动、设备树配置或混音器状态可能有问题这时候再怎么调应用层代码都没用。我调试过一个板子aplay -l能列出设备但实际播放全是杂音查到最后是I2S引脚配置错误系统时钟根本没到位——这类问题靠应用代码是永远无法解决。2.3 “default”和“hw:0,0”怎么选ALSA的设备名字看起来简单实际暗藏玄机。最常用的三个default、hw:0,0、plughw:0,0。default是ALSA配置层定义的虚拟设备会自动做格式转换、采样率匹配、声卡选择等对新手最友好也是我推荐大多数场景直接使用的。缺点是会引入额外延迟和重采样不适合对参数和延迟要求苛刻的场景。hw:0,0表示直接访问第一张声卡的第一个设备不做任何软件转换。它会以最快的路径把数据送到硬件但前提是你给的参数硬件必须原样支持比如硬件只支持48000Hz你非要用44100snd_pcm_set_params会直接报错。这里0,0是card编号和设备编号具体看aplay -l的输出。plughw:0,0介于两者之间它允许插件层做必要的格式转换但目标设备是明确指定的。灵活性比hw:0,0好又没有default那么不可控。对菜鸟来说先用default跑通流程等理解了参数的含义再根据自己的业务需求选hw或plughw完全来得及。3. 播放实现的详细拆解让音箱出声播放链路在逻辑上比录音更简单因为不涉及混音器、麦克风增益等额外环节。我建议所有人学习ALSA时都先从播放入手跑通了再碰录音。下面用一段完整的C代码演示如何用ALSA播放一个3秒钟的440Hz正弦波。3.1 打开设备第一行代码就会遇到的错误播放的第一步是调用snd_pcm_open获得一个PCM播放句柄snd_pcm_t *playback_handle; int err snd_pcm_open(playback_handle, default, SND_PCM_STREAM_PLAYBACK, 0); if (err 0) { printf(PCM open failed: %s\n, snd_strerror(err)); return -1; }这里面第四个参数是模式。传0表示阻塞模式读写操作会一直等到有足够数据或缓冲区有空间为止对菜鸟最省心。如果传SND_PCM_NONBLOCK所有操作立即返回这时你必须处理-EAGAIN这类错误码新手极易搞乱。我建议初学统一用阻塞模式。snd_pcm_open最常见的报错有两个No such file or directory和Device or resource busy。前者说明设备名写错了或者声卡驱动没加载后者说明声卡被别的进程占用了。排查占用最直接的办法lsof /dev/snd/* fuser -v /dev/snd/*lsof能看到哪个进程持有声卡设备文件找到后用kill结束掉或者在代码里加一个重试逻辑。我一开始想当然地以为打开失败是自己的代码问题盲改了很久其实只是有一个后台音频服务占着设备不放。3.2 采样参数配置snd_pcm_set_params一个函数搞定大半ALSA的完整参数设置流程非常繁琐需要snd_pcm_hw_params_*和snd_pcm_sw_params_*两套接口配合。好在官方提供了snd_pcm_set_params这个简化函数它把硬件参数、软件参数、自动重采样等逻辑都封装好了非常适合入门err snd_pcm_set_params( playback_handle, SND_PCM_FORMAT_S16_LE, // 数据格式16位小端 SND_PCM_ACCESS_RW_INTERLEAVED, // 访问方式交错排列 2, // 声道数双声道 44100, // 采样率44100Hz 1, // soft_resample允许软件重采样 500000 // 缓冲时长500毫秒 ); if (err 0) { printf(PCM set params failed: %s\n, snd_strerror(err)); snd_pcm_close(playback_handle); return -1; }逐个说参数含义。SND_PCM_FORMAT_S16_LE是16位有符号小端格式兼容性最好绝大多数声卡原生支持。如果你是菜鸟千万别一开始就玩S32_LE或FLOAT_LE就算硬件支持后续数据转换也会增加无谓的复杂度。SND_PCM_ACCESS_RW_INTERLEAVED表示交错模式意思是双声道的数据按左、右、左、右的顺序交替存放在一个缓冲区里。另一种模式是SND_PCM_ACCESS_RW_NONINTERLEAVED左右声道各自独立缓冲区写起来更麻烦这里不推荐。soft_resample设为1表示如果硬件不支持目标采样率ALSA允许自动进行软件重采样。注意这个参数只有在使用default或plughw设备时才有效直接用hw:0,0时它不会生效因为hw设备禁止任何插件介入。latency单位是微秒决定了内部缓冲区的总时长。500000就是500毫秒这个值越大越不容易出现卡顿但延迟越明显。如果做语音对讲或者乐器效果器需要把延迟压到50毫秒以内如果只是播放提示音500毫秒完全够用。3.3 往PCM设备写数据writei的坑与欠载恢复配置完成后准备正弦波数据#define RATE 44100 #define CHANNELS 2 #define DURATION 3 #define FREQ 440.0 int total_frames RATE * DURATION; short *buffer (short *)malloc(total_frames * CHANNELS * sizeof(short)); for (int i 0; i total_frames; i) { short value (short)(0.3 * 32767 * sin(2.0 * M_PI * FREQ * i / RATE)); buffer[i * CHANNELS] value; // 左声道 buffer[i * CHANNELS 1] value; // 右声道 }这里total_frames是总帧数每个帧有CHANNELS * sizeof(short)字节所以申请的总字节数是total_frames * CHANNELS * sizeof(short)也就是RATE * DURATION * 2 * 2一共1058400字节约1MB完全没问题。真正写入数据用的是snd_pcm_writei注意三个参数的含义snd_pcm_sframes_t written snd_pcm_writei(playback_handle, buffer, total_frames); if (written 0) { written snd_pcm_recover(playback_handle, written, 1); } if (written 0 written total_frames) { // 说明部分帧还没写完需要把剩余帧重新提交 snd_pcm_writei(playback_handle, buffer written * CHANNELS, total_frames - written); }snd_pcm_writei的第三个参数是帧数不是字节数。写成字节数是一个非常经典的错误。很多新手直接传total_bytes结果播放出来是一段尖锐的爆音因为驱动把每4个字节当成一帧去解释左右声道和数据边界全乱了。written返回的是实际写入的帧数。如果返回值是负数表示出错了。最常见的是-EPIPE也就是underrun欠载——意思是驱动需要的音频数据没能及时送达缓冲区已经空了。这在播放场景中极其常见尤其当程序在写入前做了耗时操作比如打开文件、计算数据缓冲区就被耗光了。欠载发生后PCM设备会自动进入XRUN状态这时必须调用snd_pcm_recover恢复// recover的第二个参数1表示阻塞等待恢复完成 snd_pcm_recover(playback_handle, written, 1);snd_pcm_recover内部会根据错误码自动决定是prepare还是别的恢复操作这是官方推荐的错误处理方式。如果不想依赖它也可以手动调用snd_pcm_prepare但recover更省心。3.4 为什么会出现卡顿和爆音从buffer_size看起播放卡顿的直接元凶就是underrun。数据写给驱动的速度跟不上硬件消费的速度缓冲区空了声卡就只能输出一两帧空白耳朵听到的就是咔哒一下。想减少卡顿第一件事是确认缓冲区大小和period大小的关系。snd_pcm_set_params虽然自动设置了buffer但默认策略不一定适合你的场景。如果你需要更精细的控制可以在设置完参数之后用snd_pcm_get_params查询实际值snd_pcm_uframes_t buffer_size, period_size; snd_pcm_get_params(playback_handle, buffer_size, period_size); printf(buffer_size %lu frames, period_size %lu frames\n, buffer_size, period_size);一般buffer_size是period_size的2到4倍。period越小系统唤醒应用的频率越高实时性越好但CPU开销越大period越大批处理效率高但延迟越明显。在嵌入式板卡上如果出现频繁卡顿我通常会尝试把period调大或者用snd_pcm_hw_params_set_buffer_time_near主动设置期望的缓冲时间。还有一个容易忽略的点往缓冲区写入时如果用memcpy把大量数据一次性塞给snd_pcm_writei内部其实会把数据切成period尺寸每次触发一次唤醒。如果两个period之间的数据生成得太慢就会欠载。所以更稳妥的做法是按period分批写入——每次只写一个period的帧数然后休眠到接近数据传输时间再写下一批。这个思路在录音环节同样适用。爆音则多半和数据格式有关。比如声卡实际是SND_PCM_FORMAT_S16_BE大端你用S16_LE写数据高低字节颠倒输出的声音就是失真爆音。另外幅度过大导致削波也会爆音正弦波生成代码里的0.3就是衰减系数防止超出short的最大范围。4. 录制实现的详细拆解把声音接进内存播放打通之后录音就是反过来的数据流声卡麦克风采集到的模拟信号转成PCM数据应用端负责用snd_pcm_readi循环读取。录音环节更容易出问题因为除了PCM参数之外还牵扯到音频通路、混音器、增益等硬件状态。4.1 打开录音设备的差异化配置打开录音设备时把流方向参数换成SND_PCM_STREAM_CAPTUREsnd_pcm_t *capture_handle; int err snd_pcm_open(capture_handle, default, SND_PCM_STREAM_CAPTURE, 0); if (err 0) { printf(Capture open failed: %s\n, snd_strerror(err)); return -1; }参数配置和播放几乎一样区别在于录音场景下latency直接决定你能容忍的延迟。如果用default设备做录音建议latency设置100毫秒左右。太大容易造成录制的声音和实际动作不同步的错觉太小则容易overrun数据溢出也就是应用读取不够快缓冲区满了新采集的数据被丢弃。具体参数上我用16kHz单声道16bit做语音识别类项目用44.1kHz双声道做音乐录制。前者数据量小、处理快后者保留更多频响细节。4.2 readi主循环数据怎么一块一块来录音的核心是一个readi循环不断从设备读取新数据#define CAPTURE_RATE 16000 #define CAPTURE_CHANNELS 1 #define CAPTURE_SECONDS 3 #define PERIOD_FRAMES 256 short *pcm_buf (short *)malloc(PERIOD_FRAMES * CAPTURE_CHANNELS * sizeof(short)); int total_frames CAPTURE_RATE * CAPTURE_SECONDS; int frames_read 0; while (frames_read total_frames) { snd_pcm_sframes_t got snd_pcm_readi(capture_handle, pcm_buf, PERIOD_FRAMES); if (got -EPIPE) { // overrun读得太慢数据被覆盖 snd_pcm_recover(capture_handle, got, 1); continue; } if (got 0) { snd_pcm_recover(capture_handle, got, 1); continue; } // got 0表示成功读取的帧数 fwrite(pcm_buf, sizeof(short), got * CAPTURE_CHANNELS, fp); frames_read got; }每次readi请求的帧数最好和period_size保持一致。如果你不问驱动就随便传一个数驱动内部也会拆成period粒度处理但多一层转换就多一分不可控。got有可能小于你请求的帧数这就是数据还够一个period所以循环里必须用frames_read累计不能假设每次读都是满的。我之前想当然地认为一次readi一定能返回256帧结果循环少读了数据录出来的声音加快、音调变高——因为数据被截短了。录完别忘了收尾snd_pcm_drain(capture_handle); // 把残余数据读进来 snd_pcm_close(capture_handle);注意录音这里的drain是为了把缓冲区内尚未读出的数据拿完。但有时候drain会等待后续新数据而阻塞如果你的录音循环已经退了再调drain可能卡住。更稳妥的做法是在循环里按预计总帧数读够然后直接snd_pcm_close。实际项目中我通常直接close需要精确补零的话再单独处理。4.3 把录音数据落成一个WAV文件很多时候录完的数据需要存成文件。WAV文件是最简单的音频容器它只需要在PCM裸数据前加一个44字节的文件头。构造WAV头的关键字段typedef struct { char riff_tag[4]; // RIFF unsigned int riff_size; // 文件总大小 - 8 char wave_tag[4]; // WAVE char fmt_tag[4]; // fmt unsigned int fmt_size; // 16 unsigned short audio_format; // 1表示PCM unsigned short num_channels; // 声道数 unsigned int sample_rate; // 采样率 unsigned int byte_rate; // sample_rate * num_channels * bits_per_sample / 8 unsigned short block_align; // num_channels * bits_per_sample / 8 unsigned short bits_per_sample;// 16 char data_tag[4]; // data unsigned int data_size; // PCM数据大小 } WavHeader;写入文件时先写文件头再写入读取到的PCM数据。最后全部数据写完后需要回到文件开头更新riff_size和data_size两个字段因为它们必须等于真实的文件大小。WavHeader header; // ... 填充字段 fwrite(header, sizeof(header), 1, fp); // ... 写PCM数据 // 写完数据后回去更新header int data_bytes frames_read * CAPTURE_CHANNELS * sizeof(short); header.data_size data_bytes; header.riff_size 36 data_bytes; fseek(fp, 0, SEEK_SET); fwrite(header, sizeof(header), 1, fp); fclose(fp);WAV头是小端字节序。x86和ARM平台默认小端直接按结构体写入没问题如果你用的是大端平台需要手动把字节翻转。我最初在模拟器上跑出来的WAV文件在PotPlayer里能播放但放手机上不认排查半天发现是riff_size字段写晚了导致文件头不完整。4.4 录出来是杂音、音量小甚至全无声时怎么办录音出问题比播放多得多这里列一个我整理的排查顺序。无声八成不是PCM参数问题而是音频通路被静音或根本没接通。Linux声卡的混音器mixer是独立于PCM设备的一套控制机制。有些板子的codec默认把捕获通路静音或者麦克风增益为0。先用amixer查看amixer scontrols amixer sget Mic amixer sset Mic 80% unmute capunmute cap表示取消静音并设置在录音方向可用。不同codec的控件名不一样常见的有Mic、Capture、ADC、Input Gain。如果amixer scontrols列出的控件里没有Mic说明硬件上可能压根没接麦克风或者设备树里音频路由没配置正确。杂音先检查采样格式。如果你用S16_LE配置设备但实际数据其实是8bit或者32bit高低位错位就会出现持续的电流嘶嘶声。另外采样率和发射端不匹配也会导致音调偏移和杂音。一个简单判断方法用arecord -f cd录制CD音质44.1kHz双声道16bit如果同样杂音说明是硬件或混音器问题如果正常说明是代码参数问题。音量小往混音器增益方向查。amixer sset Mic 80%提高音量如果输入源是Line In而不是Mic需要切换输入源。还有一种可能是单声道数据被当成了双声道处理左右声道互相抵消音量听着就小了一半。5. 录音和播放同时进行的全双工场景三个容易翻车的点很多人把播放和录音单独跑通之后兴冲冲把两段代码拼在一起结果发现一边出声一边录音断断续续或者声音变得忽快忽慢。这不是代码移植的问题而是全双工场景特有的几个坑。5.1 两个独立句柄参数必须各自验证ALSA的标准做法是给播放和录音分别创建独立的PCM句柄snd_pcm_t *playback_handle; snd_pcm_t *capture_handle; snd_pcm_open(playback_handle, default, SND_PCM_STREAM_PLAYBACK, 0); snd_pcm_open(capture_handle, default, SND_PCM_STREAM_CAPTURE, 0);两个句柄各自配置参数互不影响。但有一个原则尽量让两边的采样率、声道数、数据格式保持一致。如果一边是44100Hz双声道另一边是16000Hz单声道即便程序能跑数据的处理逻辑也会变得极其拧巴。我见过有人图省事播放用48000、录音用44100结果录下来的声音明显变调——因为读取数据的速度和真实发声不匹配。全双工场景下先统一采样率最能避免这类玄学问题。5.2 录音和播放相互“拽”导致的时钟漂移问题即使两边都设置成相同的采样率实际运行中也会出现越跑越偏的情况。原因是播放设备的时钟和录音设备的时钟来自不同晶振源误差虽然微小通常几十ppm但长时间累积后录音数据可能比播放数据多一点或少一点导致缓冲队列要么溢出要么空虚。最简单的应对办法是用同一张声卡。多数声卡的全双工时钟是同一源的互相之间不会漂移。如果必须用两张声卡就要做重采样或者定期补偿比如播放端数据不足时插入静音帧录音数据过多时丢弃部分帧。这些补偿策略写起来比较麻烦菜鸟阶段不需要深入但心里要清楚声音延迟越来越大不是你的代码抽风而是时钟漂移。另外一个降低风险的手段是调整buffer大小。录播同时进行时把两个设备的buffer都调大一些latency设300毫秒以上系统调度抖动不容易直接把缓冲区击穿。代价是延迟变大但作为初学稳定优先。5.3 排查手段ALSA_DEBUG与lsof实战全双工出现问题后靠printf看数据量是没办法快速定位的。ALSA库自带调试输出功能你不用改代码就能开启ALSA_DEBUG1 ./my_audio_appALSA_DEBUG的值是1到6数字越大输出越详细。设置成3通常就能看到PCM设备的打开、参数协商、状态切换等关键日志。它会打出类似ALSA lib pcm.c:xxxx:(snd_pcm_open_noupdate) Unknown PCM ...这样的信息能直接告诉你设备名错误、参数不支持等根因。还可以用strace跟踪系统调用strace -f -e traceioctl ./my_audio_appALSA的用户态库最终是通过ioctl访问驱动所以strace能看到每次调用传入的数据结构。如果发现某个ioctl返回EBUSY或者EINVAL结合ALSA_DEBUG的输出就能定位是Open的参数有问题还是配置流程不对。再有就是前面提到的lsof和fuser。一旦出现Device or resource busy别急着改代码先看看哪个进程偷占了声卡。我就遇到过系统自带的音频服务在后台悄悄挂着设备导致应用打开失败排查了很久才发现是服务冲突。6. 菜鸟练完这一轮的实战心得到这里播放、录制、全双工三个场景的代码路径都讲完了。最后分享几条我实际操作中的体会也是反复踩坑之后的总结。第一始终坚持“先命令行后代码”的验证顺序。aplay和arecord是ALSA官方自带的测试工具它们能跑通才说明你的设备、驱动、混音器都没问题。直接上代码遇到问题你很难分清到底是自己的逻辑错还是底层环境错。我每次换一块新板子第一件事永远是跑aplay和arecord。第二每个函数的返回值都必须处理。ALSA的API没有异常机制全靠返回值传递错误码。很多菜鸟只在snd_pcm_open失败时打印错误后面snd_pcm_writei、snd_pcm_set_params的返回值一概忽略。实际项目中-EPIPE这类运行时错误是必然会发生的事情你写日志的时候把这些返回值都打出来后面调bug才能有的放矢。第三数据流和参数检查要分步。音频程序最麻烦的地方在于有时候代码完全“正确”但声音就是不对。这时先检查设备名再检查采样格式和采样率最后检查数据本身——把这三个环节拆开逐一验证定位速度会快很多。比如我在一个项目里播放WAV文件老是有杂音最后用十六进制工具比对原始WAV数据才发现是文件本身带了一个合唱效果器插件生成的浮点数据根本不是ALSA的问题。第四把每次调试过程写成笔记。标题里的“菜鸟修炼笔记”说的就是这件事——音频开发涉及的细节多且零散不记录下来过两个月再碰肯定又忘干净。笔记不用很长关键记录四件事设备环境、参数配置、完整的源码、遇到的问题和解决过程。这些笔记积累起来就是你自己最宝贵的调试手册。ALSA的学习曲线确实陡峭但它的核心逻辑其实很简单打开设备、配置参数、读写数据、处理错误。只要把数据流的方向和术语概念搞清楚从菜鸟到能独立实现录放功能并没有想象中的那么远。希望这篇笔记能帮你少走一些弯路。
