音频延迟：麦克风与扬声器延迟测量

2026-04-13发布 8分钟阅读

摘要 (TL;DR)

我以前用一块旧 USB 接口录原声吉他，监听耳机里大约有 35 ms 的往返延迟——任何节奏短句弹起来都像在湿沙里走。换成 MOTU M2 加配置好的 ASIO 驱动后降到 5 ms 区间，同一条 take 从”无法弹”立刻变成”自然”。这不是 bug，是一种可测量、物理的现实，叫往返延迟（round-trip latency, RTT）。RTT 是五段之和：麦克风信号填输入缓冲、宿主软件处理那段缓冲、处理后信号填输出缓冲、DAC 转回模拟、最后空气传播到耳（约 34cm 每 1ms）。可调节部分主要在缓冲大小和驱动模型；ASIO、WASAPI Exclusive、Core Audio、JACK 各自典型最低值与平台限制不同。本文讲这些组件如何叠加、采样率/缓冲大小取舍为何不像直觉那样、以及如何用回环线 + 测试音 + 音频编辑器实测端到端延迟——而不是相信营销页”1ms”。

背景与概念

麦克风到扬声器之间，电脑做的事比多数人意识到的多。ADC 按选定采样率（常 48kHz）采样麦克信号，把样本收进输入缓冲。缓冲填满（比如 48kHz 下 128 样本，约 2.67ms 音频）后驱动把它交给应用。

应用（DAW、通信客户端、浏览器）处理那段缓冲、应用效果或为网络传输编码、再把结果写进输出缓冲。输出缓冲填满后 DAC 把它转成模拟信号离开耳机或线路输出。

接着是计算机外的世界。声音在常温下约 343 m/s，每 34cm 约 1ms。耳机基本不加这一段；房间另一头的监听音箱再加几毫秒。坐 1.7m 远的一对监听音箱前，单是空气传播就贡献约 5ms——规格表上看不见但耳朵里在。

所以往返延迟 = 输入缓冲 + 处理 + 输出缓冲 + DAC + 传播。采样率固定时，缓冲越小延迟越低但 CPU 负担越大，因为音频线程要更频繁醒。如果缓冲按样本数而不是按时间设，提采样率会把”N 样本”的缓冲在毫秒上变短——但更高采样率也提高吞吐、对驱动施压不同，所以这不是免费降低延迟的途径。

驱动模型在应用与音频硬件之间，自身有延迟特性。Windows 上经典 MME 与 DirectSound 路径为兼容性加大量缓冲；WASAPI Shared 更低但仍由混音器中介；WASAPI Exclusive 与 ASIO 绕开多数那种开销。ASIO4ALL 是通用 ASIO 包装器，厂商 ASIO 不可用时有用，但不能替代真正的厂商 ASIO 驱动——同一块 Focusrite Scarlett 2i2 第三代实测 RTT，用官方驱动通常显著低于 ASIO4ALL 套在 WASAPI 上。macOS 上 Core Audio 作为平台默认就为低延迟调过。Linux 上 JACK 与 PipeWire 配置好可以做到很低延迟，但需要实时内核调度才能稳定。

对比与数据

维度ASIOWASAPI ExclusiveCore AudioJACK
平台主要 Windows仅 Windows仅 macOSLinux 为主，跨平台移植存在
典型最低延迟非常低，常在低毫秒级独占模式下低在低毫秒级稳定良好配置时极低，但配置复杂
共享模型取决于驱动（通常独占）共享/独占可选，独占延迟更低调好的共享模式是默认基于路由矩阵，多客户端

精确毫秒数严重依赖硬件、驱动、OS 版本，所以不要相信产品页的”1ms 延迟”——给自己系统测一次建立基线更实用。MOTU M2、Focusrite Scarlett 2i2 第三代这种平价接口配上正经 ASIO 或 Core Audio 驱动能进个位数毫秒往返；同样硬件走 Windows 共享模式 WASAPI 路径或被 ASIO4ALL 包一层通常明显更差。你的真实 RTT 是接口、驱动、缓冲三个变量的联合结果，孤立假设其中一个很少准确。

实战场景

场景 1 — 现场表演与入耳监听。歌手通过入耳监听听自己声音时，几毫秒延迟就会被感觉成时机问题。这里目标是 RTT 低于 10ms，通常需要小缓冲、低延迟驱动（Windows 上 ASIO，macOS 上 Core Audio），并且尽可能用接口的硬件直接监听——它把监听信号完全绕开软件路径。MOTU M2 的前面板监听旋钮一拧就解决，Scarlett 2i2 第三代的”Direct”开关同理。

**场景 2 — 播客录制。**除非多名主持要互相实时监听，录制时 50–100ms RTT 通常够用。后期反正要对轨，加大缓冲改善 CPU 余量，反而降低长录制中爆音风险。这里追低延迟常常帮倒忙。

**场景 3 — 视频会议。**浏览器 WebRTC 通话端到端通常 100–200ms 左右——本地音频延迟之上还叠了网络、编码、抖动缓冲。这接近对话轮替仍能感觉自然的边界；加上老编解码的蓝牙耳塞可能把它推过那个阈值，参与者就开始抢话。

**场景 4 — 在线音乐协作。**通过互联网与远端伙伴同步演奏是这条频谱里最不留情面的一端。单向延迟超过约 25–30ms 就难维持稳定节奏，普通家庭网络 + 消费级音频软件常常远远超出这一档。专门的低延迟协作平台存在就是为了刮掉每一个可能的毫秒，即便如此通常仍要求有线以太、细致驱动调优、以及在互联网骨干上的物理临近。意识到消费级视讯通话栈不是干这活的对的工具，通常是第一步。

常见误解

**“蓝牙音频一定高延迟。“**经典 A2DP 流确实加显著延迟。但更新的 LE Audio (LC3) 与 aptX Low Latency 编解码把它降到相当低的区间，这是感官层级的变化。两副都说”蓝牙”的耳机根据所支持编解码不同体感可能差很大。但录音监听场景，有线仍是更稳的选择。

“USB 音频总是好过模拟。“当接口有好 DAC、干净前置、稳定驱动时，USB 接口确实优于板载模拟；但便宜的 USB DAC 因抖动、噪声、驱动问题反而可能更差。光”USB”不代表质量，组件选择才是。

“192kHz 采样率延迟更低。“反直觉但重要：如果缓冲按时间（ms）指定，提高采样率不会减少物理延迟。只有在缓冲按样本数固定时，更高采样率才意味着每缓冲毫秒数更少——代价是每秒数据更多、CPU 更高、驱动压力更大。低延迟主要来自更小缓冲与更好驱动模型，不是更高采样率。

**“软件监听和硬件监听感觉一样。“**不一样。软件监听把麦信号走一遍 DAW 路径——输入缓冲、插件处理、输出缓冲——一路累积 RTT。音频接口的硬件监听在接口内部把麦信号直接送到耳机输出，监听路径完全绕开电脑。演奏者听到的延迟实质为零，电脑仍在录后期用的轨。许多设置把两者搞混，把硬件监听一个开关就能消除的延迟怪到缓冲大小上。

决策清单或决策流

  1. **定义用例的 RTT 目标。**现场表演 <10ms；录音 50–100ms；会议 100–200ms 现实可行。
  2. **选驱动模型。**Windows 上 ASIO 或 WASAPI Exclusive；macOS 上 Core Audio；Linux 上 JACK 或 PipeWire。默认共享模式栈（MME、默认共享 WASAPI）通常延迟最高。
  3. 逐步降缓冲直到刚好爆音前。那是该系统的实操下限。
  4. **做一次回环测量。**用线把接口输出连回输入，放测试音，在音频编辑器里读捕获波形的时间差。
  5. **采样率匹配项目需求。**视频常 48kHz，音乐 44.1/48kHz。再往上要有具体理由。
  6. 明智用监听路径。尽量用接口的直接监听给演奏者听，让监听 RTT 实质为零，即便录音路径本身有几毫秒延迟。

相关工具

Patrache Studio 音频延迟工具 在浏览器里估算往返延迟，无须买硬件就能拿到大致读数。游戏语境下更广义的”输入延迟”图景见 键盘 N-Key Rollover (NKRO) 与游戏输入延迟。如果在调音频延迟影响 A/V 同步的视讯通话设置，把本文与 摄像头诊断：帧率、分辨率与光线的相关性 配合，理解叠在音频之上的相机端延迟。

参考资料

相关工具

diagno.patrache.studio/audio/latency/