还是有点懒，先放个 AI 总结。

另见dmald

---

真忍不了了，先删点看不下去的和正确性明显有问题的内容

---

在进行Linux下的专业音频制作时，你是否曾被莫名的爆音、卡顿所困扰？即便调大了音频缓冲区，问题依旧幽灵般闪现？这一切的根源，很可能指向一个深藏在内核中的机制——DMA Latency。

实时音频处理就像一个永不停止的传送带。声卡通过DMA（直接内存访问）控制器，将采集到的音频数据放入内存缓冲区，或从内存中取走处理好的数据播放。这个过程本不需CPU过多干预。

然而，CPU这个“监工”却有一个坏习惯：偷懒睡觉（进入节能的C-State）。当DMA完成工作，发出中断信号叫醒CPU来处理下一块数据时，如果CPU处于深度睡眠（如C6状态），它需要几百微秒才能醒来。

就是这几百微秒的延迟，足以让实时音频的精密流水线崩溃——新的数据覆盖了旧数据，或播放指针遇到了尚未准备好的数据，其结果就是爆音和卡顿。 XRUN

/dev/cpu_dma_latency

1. 打开文件
2. 写入0 表示你要求系统最大延迟不能超过0微秒。
3. 最关键的一步：保持文件描述符打开！ 只要文件描述符不关闭，这个请求就一直有效。一旦关闭，内核便认为你放弃了请求，系统将恢复常态。

为什么必须是“0”？

发现：任何非零的延迟设定，其效果与完全不设几乎无异。

这揭示了内核C-State管理的“悬崖效应”：

• latency = 0: 内核被禁止让CPU进入任何C1以上的深度睡眠状态。CPU时刻保持高度警觉，响应延迟极低且恒定。此时，DSP负载曲线是一条平稳的直线，音频流畅无比。
• latency = 50: 内核允许CPU进入唤醒延迟≤50us的状态。然而，C1/C2等浅度睡眠的省电效果微乎其微，但其状态切换带来的微小延迟波动，已足以破坏音频处理的微秒级确定性。DSP负载再次出现剧烈波动。
• latency = 未设定: CPU自由进入最深的C-State，唤醒延迟可能超过150us。结果就是持续的爆音和极高的DSP负载峰值。

结论是残酷的：在实时音频领域，没有中间道路。唯有极致的 0，才能换来绝对的稳定。

当然，天下没有免费的午餐。设定 cpu_dma_latency=0 的代价是显著的：

• 功耗增加：CPU无法深度节能，耗电量上升。
• 温度升高：即便在轻负载下，CPU核心温度也可能比正常情况高出10°C以上。

---