1. 为什么值得花时间搞懂 arecord 和 aplay

很多人第一次在 Linux 上碰音频，都是从一条命令开始的：想录个音，搜到arecord；想放个声音，搜到aplay。命令敲下去，能响、能录，任务就算完成了。但只要稍微往深走一步——比如录出来的文件是空的、播放速度不对、麦克风有杂音、多声卡环境下设备选错——立刻就会卡住，因为网上大部分教程只告诉你“敲这条命令”，没人告诉你这条命令背后到底发生了什么。

这篇内容就是来解决这个问题的。arecord和aplay是 ALSA（Advanced Linux Sound Architecture）工具集里最基础、也最容易被低估的两个命令行工具。它们不是简单的“录音机”和“播放器”，而是直接跟内核音频子系统对话的探针。你把它们用明白了，等于手里有了一把能拆开整条音频链路的手术刀：从应用层参数、到 ALSA 库的缓冲管理、到内核驱动、再到硬件采样时钟，每一层出了什么问题，都能通过这两个工具的参数和输出定位出来。

适合谁来读？如果你是在嵌入式设备上调试音频的开发者、是在服务器上做语音采集的后端工程师、是刚接触 Linux 桌面想搞清楚声卡配置的爱好者，或者只是被“录出来全是噪音”折磨过的人，这篇都值得从头看到尾。我会从 ALSA 的整体架构讲起，把arecord/aplay的底层原理拆开，然后给出一套可以直接抄作业的实操流程，最后把我自己踩过的坑整理成排查表。全程用大白话加实际命令，不堆术语，但该有的深度一点不少。

先给个心理预期：这两个工具的参数看起来多，但真正天天用的就那么十来个。搞懂其中五六个核心参数的含义，你就能覆盖 90% 的日常场景。剩下的，等真遇到问题了再查表也不迟。

2. ALSA 音频链路的整体设计与工具定位

2.1 从“声音进耳朵”倒推整条链路

要理解arecord和aplay，得先知道声音在 Linux 里是怎么流动的。我习惯用“水管”来类比：声音数据就是水，从源头（麦克风或音频文件）流到终点（扬声器或磁盘文件），中间要经过好几段管道，每一段都有自己的阀门和缓冲池。

以录音为例，完整链路是这样的：麦克风把声波转成模拟电信号，声卡上的 ADC（模数转换器）按固定时钟把它采样成数字信号，数字信号进入内核里的 ALSA 驱动，驱动把它写进一块环形缓冲区（ring buffer），用户态的arecord通过 ALSA 库（libasound）不断从这块缓冲区里把数据读出来，最后写到磁盘上的 WAV 文件里。播放则是反过来：aplay读文件，写进环形缓冲区，驱动把数据推给 DAC（数模转换器），DAC 转成模拟信号推给扬声器。

这条链路里有两个关键概念必须记住：period（周期）和buffer（缓冲区）。缓冲区是整块内存池，周期是每次硬件中断搬运的数据量。你可以把缓冲区想成一个传送带，周期就是传送带每次往前挪一格的距离。传送带太小，数据来不及搬就溢出（录音丢帧）或者断流（播放卡顿）；传送带太大，延迟就高，录出来的声音和实际动作对不上。arecord/aplay的很多参数，本质上都是在调这条传送带的格数和每格大小。

2.2 为什么是命令行工具而不是图形界面

有人会问，现在桌面环境都有音量控制面板，为什么还要用命令行？原因很实在：图形工具是封装好的黑盒，它替你做了设备选择、格式协商、缓冲配置，一旦出问题你根本不知道它选了什么。而arecord/aplay把每一个决策都暴露成参数，你能精确控制采样率、位深、声道数、设备名、缓冲大小，出问题时也能通过-v把协商结果打印出来。

更关键的是，在无图形界面的服务器、嵌入式板子、容器环境里，图形工具根本不存在，命令行是唯一选择。我做过一个语音采集的后端服务，跑在没装桌面的机器上，整个音频链路就是靠arecord加管道喂给处理程序，稳定跑了大半年。这种场景下，图形工具毫无用武之地。

2.3 arecord 与 aplay 在工具集中的位置

ALSA 工具集里其实有一堆命令：amixer调音量、alsactl存配置、speaker-test测声道、aconnect连 MIDI。arecord和aplay属于“数据搬运工”这一层，专门负责 PCM 音频流的输入输出。它们共享同一套底层库和几乎相同的参数体系（aplay的参数arecord基本都有，反之亦然），所以学会一个，另一个自然就会。

这里有个容易混淆的点：arecord录出来的默认是 WAV 格式（带文件头），aplay能直接播 WAV。但如果你用-t raw指定裸流，那就没有文件头，播放时必须手动告诉它格式参数，否则出来的就是噪音。这个细节后面会专门讲，因为它是新手翻车的高发区。

3. 核心参数与底层原理拆解

3.1 设备名：hw 与 plughw 的区别决定了你能不能出声

arecord -D和aplay -D后面跟的设备名，是整个工具里最容易被忽略、又最影响结果的东西。常见写法有三种：hw:0,0、plughw:0,0、default。

hw:0,0表示直接访问 0 号声卡的 0 号设备，不做任何格式转换。这意味着你给的采样率、位深、声道数必须和硬件支持的一模一样，差一点就报错Invalid argument。它的好处是延迟最低、路径最短，适合对时序敏感的场景。

plughw:0,0则在hw前面加了一层“插件”（plug），ALSA 会自动帮你做采样率转换、位深转换、声道重映射。你给 44100Hz，硬件只支持 48000Hz，它会默默帮你转，不报错。代价是多了一次软件转换，延迟略高、CPU 略高，但兼容性极好。

default是 ALSA 配置里定义的一个别名，通常指向系统默认设备，具体行为取决于配置文件，可能带插件也可能不带。

我的经验是：调试阶段一律先用plughw或default把声音跑通，确认链路没问题后，再换成hw去压延迟。反过来做，你会被一堆Invalid argument搞得怀疑人生，还以为是硬件坏了。

3.2 采样格式：S16_LE 为什么是默认答案

-f参数指定采样格式，常见值有S16_LE、S24_LE、S32_LE、FLOAT_LE。S代表有符号整数（signed），16是位深，LE是小端序（little-endian）。S16_LE就是 16 位有符号小端整数，每个采样点占 2 字节。

为什么它是默认？因为绝大多数消费级声卡的原生格式就是 16 位，CD 音质也是 16 位 44.1kHz，兼容性最好。24 位和 32 位虽然动态范围更大，但很多板载声卡并不原生支持，走hw会直接失败，走plughw又会被降转回 16 位，等于白设。

这里有个计算值得说清楚：数据率 = 采样率 × 位深 × 声道数。以 44100Hz、16 位、双声道为例，每秒数据量是 44100 × 2 字节 × 2 = 176400 字节，约 172KB/s。这个数字决定了你录一小时大概占多少磁盘：172KB/s × 3600s ≈ 620MB。如果你用 48000Hz、24 位、双声道，就是 48000 × 3 × 2 = 288000 字节/s，一小时约 1GB。做长时间录音前先算这笔账，能避免磁盘写满的尴尬。

3.3 周期与缓冲区：延迟和稳定性的跷跷板

--period-size和--buffer-size是进阶参数，但理解了它们，你才算真正摸到 ALSA 的脉搏。

前面说过，缓冲区是环形内存池，周期是每次硬件中断搬运的量。假设缓冲区 8192 帧，周期 1024 帧，那么缓冲区能装 8 个周期。录音时，硬件每填满一个周期就发一次中断，arecord收到中断就来取数据。如果arecord取数据的速度跟不上硬件填数据的速度，缓冲区就会溢出（overrun），表现为录音丢帧、爆音。播放时反过来，如果aplay供数据的速度跟不上硬件消耗的速度，缓冲区就欠载（underrun），表现为卡顿、断音。

延迟的粗略估算公式是：延迟 ≈ 周期大小 / 采样率。周期 1024 帧、采样率 48000Hz，单周期延迟约 21ms；周期 256 帧，约 5.3ms。周期越小延迟越低，但中断越频繁，CPU 负担越重，也越容易欠载。所以这是个权衡：实时通话、乐器输入这类场景要小周期低延迟；长时间录音、背景采集这类场景要大周期求稳定。

我一般先用默认值跑，出现 overrun/underrun 再逐步调大周期和缓冲区，每次翻倍，直到稳定为止。盲目设一个很大的值虽然稳，但延迟高得没法用，属于矫枉过正。

3.4 声道与采样率：别让硬件替你猜

-c指定声道数，-r指定采样率。这两个参数如果和硬件不匹配，走hw会报错，走plughw会被静默转换。静默转换最坑的地方在于：它不报错，但结果可能不是你想要的。比如你录单声道，硬件是立体声，插件可能把两个声道混成一个，也可能只取一个，具体行为取决于配置，你不看文档根本猜不到。

所以我的习惯是：先用arecord -l和arecord --dump-hw-params -D hw:0,0把硬件的真实能力打印出来，照着它支持的格式去设参数。--dump-hw-params会列出该设备支持的采样率范围、位深、声道数、周期范围，这是最权威的信息来源，比任何网上教程都靠谱。

4. 从零到一的实操流程

4.1 第一步：确认声卡被系统识别

动手之前先确认硬件在不在。两条命令：

arecord -l aplay -l

输出会列出所有录音设备和播放设备，格式类似card 0: xxx [xxx], device 0: xxx [xxx]。card后面的数字和device后面的数字，组合起来就是设备名hw:0,0。如果这两条命令输出为空或者报no soundcards found，说明驱动没加载或者硬件没被识别，后面所有操作都无从谈起，得先去查驱动。

我遇到过一种情况：板子上声卡明明在，但arecord -l只显示播放设备不显示录音设备。后来发现是设备树里麦克风那一路没使能，属于硬件配置问题，跟 ALSA 无关。所以看到设备列表不全，先怀疑硬件和驱动，别急着调参数。

4.2 第二步：用 speaker-test 验证播放通路

在折腾录音之前，先把播放跑通，这样你才有“参照物”。speaker-test是 ALSA 自带的测试工具：

speaker-test -D plughw:0,0 -c 2 -t sine -l 1

-c 2是双声道，-t sine是正弦波，-l 1是播放一轮。正常的话你会听到左右声道轮流响。如果没声音，先查amixer的静音状态和音量，再查设备名对不对。这一步跑通了，说明播放链路（驱动、DAC、扬声器）没问题，后面aplay出问题就只可能是文件或参数的事。

4.3 第三步：录一段音并回放验证

录音命令：

arecord -D plughw:0,0 -f S16_LE -r 44100 -c 2 -d 5 test.wav

-d 5表示录 5 秒后自动停止。录完用aplay回放：

aplay -D plughw:0,0 test.wav

能听到自己的声音，闭环就算打通了。这里有个细节：aplay播放 WAV 时会自动从文件头读取格式参数，所以你不需要再指定-f -r -c。但如果你录的是裸流（-t raw），播放时就必须手动补上这些参数，否则出来的就是刺耳的噪音。这个不对称性是新手最容易懵的地方，记住：WAV 自带格式信息，raw 不带。

4.4 第四步：用 -v 看清协商结果

加-v参数，arecord/aplay会把实际使用的参数全部打印出来：

arecord -D plughw:0,0 -f S16_LE -r 44100 -c 2 -d 5 -v test.wav

输出里会显示Format、Rate、Channels、Period size、Buffer size等实际生效的值。这一步的价值在于：当你用plughw时，你设的参数和实际生效的参数可能不一样，-v能让你看到真相。我调试过一个案例，用户设了 44100Hz，-v显示实际是 48000Hz，说明插件做了转换，问题就定位到了采样率不匹配上。

4.5 第五步：管道玩法，把录音直接喂给处理程序

arecord支持输出到标准输出，这让它能和其它工具无缝拼接：

arecord -D plughw:0,0 -f S16_LE -r 16000 -c 1 -t raw -q - | your_processor

-t raw输出裸流，-q静默模式不打印进度，-表示输出到 stdout。这样音频数据就直接流进了下游程序，不用落盘。做实时语音识别、实时频谱分析时，这个模式非常常用。注意这里必须用-t raw，因为管道里没法塞 WAV 文件头，下游程序得自己知道格式。

5. 常见问题与排查技巧实录

5.1 录出来是空文件或者全是静音

这是最高频的问题。排查顺序我总结成一张表：

权限这块补充一句：普通用户要访问声卡，得在audio组里。临时测试可以用sudo，但长期跑服务还是把用户加进组更规范，sudo usermod -aG audio $USER，重新登录生效。

5.2 播放速度不对，声音变调

十有八九是采样率不匹配。比如文件是 48000Hz，你播放时环境默认按 44100Hz 处理，声音就会变慢变低沉。解决办法是显式指定-r：

aplay -D plughw:0,0 -r 48000 test.wav

但更根本的做法是搞清楚文件真实格式。用file test.wav或者soxi test.wav（如果装了 sox）能读出文件头里的采样率和位深，照着设就不会错。裸流文件没有文件头，file也读不出来，只能靠你自己记录录制时的参数。

5.3 多声卡环境下设备选错

机器上插了 USB 声卡、板载声卡、HDMI 音频，card 0到底是哪个，每次开机可能都不一样。靠hw:0,0硬编码迟早出事。稳妥的做法是用设备名而不是编号，比如hw:CARD=xxx,DEV=0，其中CARD=xxx是arecord -l里方括号中的名字。名字比编号稳定，换插槽也不受影响。

5.4 overrun 和 underrun 的实战处理

arecord报overrun!!!说明取数据太慢，aplay报underrun!!!说明供数据太慢。前者常见于磁盘写入慢或者下游处理卡顿，后者常见于文件读取慢或者系统负载高。

处理思路分两层：先调大缓冲换稳定，--buffer-size=16384 --period-size=4096这种量级先试；如果调大后延迟不可接受，再回头优化数据通路，比如录音时先写内存再异步落盘，播放时用--fatal-underuns之外的容错策略。我一般会先用strace -c看看是不是系统调用拖慢了节奏，有时候问题根本不在 ALSA，而在磁盘 IO。

5.5 几个只有踩过才知道的细节

第一个，arecord的-d参数单位是秒，但它是在数据真正开始流动后才计时，如果设备初始化慢，实际录到的可能比设定值短一点点，对时长敏感的场景要留余量。

第二个，用plughw做采样率转换时，转换质量取决于 ALSA 的插件配置，默认的线性插值质量一般，对音质有要求的场景最好让硬件原生支持目标采样率，走hw直通。

第三个，aplay播放超长文件时如果中途 Ctrl+C，缓冲区里的数据会丢，听起来像突然截断，这是正常现象，不是文件损坏。

第四个，容器里跑arecord需要把宿主机的/dev/snd挂进去，并且容器要有相应权限，否则arecord -l直接空列表。这个坑我在部署语音服务时踩过，排查了半天才发现是容器隔离的问题。

6. 把工具用成探针的几个进阶思路

6.1 用 arecord 做硬件能力的快速体检

--dump-hw-params这个参数值得单独拎出来说。它不录音，只打印设备支持的参数范围：

arecord --dump-hw-params -D hw:0,0

输出里FORMAT、RATE、CHANNELS、PERIOD_SIZE、BUFFER_SIZE各行列出了硬件真实支持的范围。买了个新声卡不知道它到底支持什么，跑这一条比查任何规格书都准。我习惯在给新设备写音频程序之前先跑一遍，把支持的格式记下来，后面设参数就有据可依，不会瞎猜。

6.2 用 aplay 验证裸流参数假设

手上有个来路不明的裸 PCM 文件，不知道格式？可以拿aplay当试错工具，用不同参数组合去播，听哪个组合出来的声音正常。虽然笨，但在没有元信息的情况下很有效。更聪明的做法是用sox的play -t raw -r 44100 -e signed -b 16 -c 2 file.raw逐项试，但原理是一样的：裸流没有自描述能力，格式全靠外部约定。

6.3 把录音做成可复现的脚本

生产环境里我从不手敲命令，都是写成脚本固定参数。一个最小可用的录音脚本大概长这样：

#!/bin/bash DEV="plughw:0,0" RATE=16000 CH=1 DUR=$1 OUT=$2 arecord -D "$DEV" -f S16_LE -r "$RATE" -c "$CH" -d "$DUR" \ --buffer-size=8192 --period-size=2048 -t wav "$OUT"

参数固定下来，好处是每次录出来的格式一致，下游处理不用做兼容。脚本里把设备名、采样率、声道数抽成变量，换设备时只改一处，比散落在命令里强得多。

6.4 监控音频链路的健康状态

长时间录音最怕中途悄悄断掉。可以在脚本里加一层检查：录完后用soxi读文件时长，和预期时长比对，偏差超过阈值就告警。更进一步，录音过程中用arecord -v的输出重定向到日志，事后翻日志看有没有 overrun 记录。这些手段不复杂，但能把“录了一晚上发现全是静音”这种事故挡在门外。

我个人在实际操作中的体会是，arecord和aplay这两个工具的价值，八成不在“能用”，而在“出问题时能告诉你为什么”。它们把 ALSA 的每一层决策都摊开在你面前，参数、协商结果、错误码，全是线索。真正把它们用熟之后，再遇到音频问题，你的第一反应不再是“重装驱动试试”，而是打开终端敲arecord -l和--dump-hw-params，从设备能力开始一层层往上查。这种从底层往上定位的习惯，比记住任何一条命令都值钱。