4. 延迟的度量单位
做音频开发这些年，我有个很深的体会：你写的代码再漂亮，最后都得过操作系统这一关。Windows、macOS、Linux 这三家的音频栈，设计哲学完全不同，延迟表现也天差地别。今天咱们就把它们扒开看看。
核心观点：没有绝对「最好」的平台，只有「最适合你场景」的栈。搞清楚底层怎么跑的，你才能做出正确的技术选型。
4.1 Windows WASAPI：兼容与低延迟的平衡术
Windows 的音频栈，说实话，历史包袱挺重的。从最早的 MME（多媒体扩展），到后来的 DirectSound、WDM，再到现在的 WASAPI（Windows Audio Session API），微软一直在打补丁。
WASAPI 是目前 Windows 上最推荐的音频 API。它分两种模式：共享模式和独占模式。
- 共享模式：所有应用的声音混在一起，由系统音频引擎（Audio Engine）统一处理。延迟通常在 30-100ms 之间。适合日常听歌、看视频。
- 独占模式：应用直接接管音频设备，绕过系统混音器。延迟可以降到 5-20ms。适合专业音频制作、实时通信。
我个人习惯，做现场调试时一定用独占模式。但要注意，独占模式下其他应用就没声了——有一次我调试到一半，同事喊我开会，我这边耳机里只有 DAW 的声音，系统通知全被吞了，尴尬得很。
小技巧：在 Windows 上测试延迟，可以用 IAudioClock 接口获取设备位置，配合 GetCurrentPadding 计算缓冲区占用。这是最准的方法。
WASAPI 延迟公式
总延迟 = 缓冲区大小 (样本数) / 采样率 (Hz) + 设备固有延迟 + 驱动开销
例如：256 样本缓冲区 @ 48kHz
理论延迟 = 256 / 48000 ≈ 5.33ms
实际延迟 ≈ 5.33 + 2-5ms (驱动) ≈ 7-10ms4.2 macOS CoreAudio：优雅但封闭的管道
macOS 的 CoreAudio，说实话，是我用过的最优雅的音频架构。它从底层就设计了一套统一的抽象层——AudioUnit、AudioQueue、CoreAudio HAL（硬件抽象层）。
CoreAudio 的延迟特性很稳定。为什么？因为苹果软硬件一体，驱动层优化得极好。典型的缓冲区大小和延迟对应关系：
| 缓冲区大小 | 理论延迟 (48kHz) | 实际体验延迟 | 适用场景 |
|---|---|---|---|
| 512 样本 | 10.67ms | 12-15ms | 日常播放、视频会议 |
| 256 样本 | 5.33ms | 6-8ms | 录音、乐器监听 |
| 128 样本 | 2.67ms | 3-5ms | 实时效果处理 |
| 64 样本 | 1.33ms | 2-3ms | 专业监听、现场 |
我记得有一次在 macOS 上做低延迟监听项目，用 64 样本缓冲区跑，CPU 占用率才 15% 左右。同样的配置搬到 Windows 上，独占模式 + 64 样本，CPU 直接飙到 40%，还偶尔爆音。这就是底层优化的差距。
注意：CoreAudio 的 AudioUnit 回调是在实时优先级线程上跑的。你在回调里做内存分配、文件 I/O、锁操作，系统直接给你崩掉。我曾经在回调里写了个 printf 调试，结果音频卡成狗——嗯，血的教训。
4.3 Linux ALSA/JACK：自由但需要动手
Linux 的音频栈，说白了就是「两条腿走路」：ALSA 管底层硬件，JACK 管上层实时路由。
- ALSA (Advanced Linux Sound Architecture)：内核级别的音频驱动框架。直接操作硬件，延迟可以很低，但配置起来比较折腾。
- JACK (JACK Audio Connection Kit)：运行在 ALSA 之上的音频服务器，提供低延迟、可路由的音频连接。专业音频制作、现场演出的标配。
JACK 的延迟能做到多低？我见过有人在实时内核 + JACK 的配置下，跑 32 样本缓冲区（约 0.67ms @ 48kHz）稳定运行。但代价是什么？你得自己编译内核、调优 IRQ 亲和性、关掉省电模式……
ALSA vs JACK 延迟对比
| 特性 | ALSA (直接) | JACK (通过 ALSA) |
|---|---|---|
| 最小缓冲区 | 64 样本 | 32 样本 |
| 典型延迟 | 5-15ms | 2-8ms |
| 多应用支持 | 差 (独占) | 好 (路由) |
| 配置难度 | 中等 | 高 |
| 稳定性 | 高 | 依赖内核 |
我曾经在一个嵌入式 Linux 项目上做音频采集，用 ALSA 直接 snd_pcm_readi 读数据，延迟大概 8ms 左右。后来换成 JACK + 实时内核，延迟降到 3ms，但系统稳定性下降了不少——偶尔会 xrun（缓冲区溢出）。说白了，低延迟是有代价的。
避坑指南：在 Linux 上做低延迟，一定要用 PREEMPT_RT 实时内核。我曾经在普通内核上跑 JACK，64 样本缓冲区直接爆音不断，换了实时内核后稳如老狗。
4.4 三大平台延迟特性总对比
咱们直接上表格，一目了然：
| 维度 | Windows WASAPI | macOS CoreAudio | Linux ALSA/JACK |
|---|---|---|---|
| 最小理论延迟 | ~5ms (独占模式) | ~1.3ms (64样本) | ~0.67ms (JACK+RT) |
| 典型稳定延迟 | 10-20ms | 5-10ms | 5-15ms |
| 驱动质量 | 参差不齐 (看厂商) | 统一且优秀 | 依赖硬件支持 |
| 多应用混音 | 内置 (共享模式) | 内置 | 需 JACK/PulseAudio |
| 实时优先级 | MMCSS (部分支持) | 完全支持 | 需 RT 内核 |
| 配置复杂度 | 低 | 低 | 高 |
| 适合场景 | 通用、游戏、直播 | 专业音频、音乐制作 | 嵌入式、定制系统 |
4.5 延迟架构对比图
下面这张图，我画了三个平台的音频栈层级和延迟关键点。你一看就明白差异在哪。
4.6 我的选择建议
说了这么多，到底选哪个？我个人的经验是：
- 做消费级产品（直播、语音聊天）：Windows WASAPI 共享模式就够了，别折腾。
- 做专业音频工具（DAW、效果器）：macOS CoreAudio 是首选，省心。
- 做嵌入式或定制系统（树莓派、工控机）：Linux ALSA + JACK，但要做好调优的心理准备。
嗯，记住一点：低延迟不是免费的。每降低 1ms，你可能要付出 CPU 占用率翻倍、系统稳定性下降的代价。调试的时候，先从大缓冲区开始，逐步往下压，找到那个「稳定且可接受」的平衡点。