Ardour/Synchronization/Latency-and-latency-compensation

Latency 是系统对给定刺激的反应时间。许多因素共同构成系统总 latency。要精确 time synchronization，必须计入并补偿所有 latency 来源。

1. Latency 来源
  1. 声音在空气中传播

声音是流体中的机械扰动，传播速度约 340 m/s 相对较慢。因此原声吉他或钢琴约有 1--2 ms 的 latency（声音在乐器与演奏者耳朵间传播所需时间）。

1. 1. 数模与模数转换

电信号传播极快（接近光速），传播时间可忽略。但模拟与数字域之间的转换耗时相对较长，在低 latency 系统中贡献可能可观，通常低于 1 ms。

1. 1. 数字信号处理

数字处理器倾向以块（chunks）处理 audio，块大小取决于算法需求及性能/成本考量。这通常是使用计算机时 latency 的主要来源，也是可预测与优化的部分。

1. 1. 计算机 I/O 架构

计算机是通用处理器而非数字音频处理器。Audio 数据从外部到 CPU 再返回要跨越很多环节，且与其他部分竞争资源（CPU 时间、总线带宽等）。

1. Latency Chain

下文假设使用 jackd 作为 audio backend。latency 总是可加的，是许多独立因素的总和。处理 latency 通常分为 capture latency（数字化 audio 可供数字处理所需时间，通常一个 audio period）与 playback latency（已处理 audio 可供数字播放所需时间）。实际上两者结合才重要，称 round-trip latency（捕获、处理并回放某 audio 事件所需时间）。

Ardour 中处理 latency 是可选择项，可在硬件（audio device、CPU、总线速度）与 audio driver 限制内降低。越低 latency 系统负载越高（需更频繁处理更小 audio 块），越容易错过处理 deadline 而出现 xrun（buffer over/under-run），留下 clicks、pops 与 crackles。

数字 I/O latency 对集成或 PCI audio 设备通常可忽略，但 USB 或 FireWire 接口的总线时钟与缓冲可能增加几毫秒。

1. 低 Latency 使用场景

低 latency 并非总是所需——它伴随一些缺点：最突出的是功耗增加（CPU 持续处理大量小块 audio 数据、无法进入省电模式）；信号链上每个应用都必须运行在每个 audio cycle，低 latency 系统会经历更多 context switches，开销显著，导致系统负载更高、xrun 概率更大。

对少数应用，低 latency 至关重要：

演奏 virtual instruments：按键与发声间过大的 delay 会破坏多数乐器演奏者的 timing。
软件 audio monitoring：歌手通过两条路径（头骨与耳机）听到自己声音时，即使小 latency 也极令人不安，表现为刺耳恼人的声音。
Live effects：以计算机作 inline effects（如 compression 或 EQ）的 effect rack 时低 latency 重要；对 reverbs，若 direct sound 不经过计算机，稍高 latency 可能可接受。
Live mixing：用计算机混音 live 演出——基本是上述组合：舞台 monitoring、effects 处理与 EQ。

在许多其他情形（playback、recording、overdubbing、mixing、mastering 等）latency 不重要，因为容易补偿。

1. Latency Compensation

tracking 时，正在回放的声音必须与正在记录的声音内部对齐，latency compensation 在此发挥作用。DAW 补偿 latency 有两条路：read-ahead 与 write-behind。DAW 提前一点开始播放（相对 playhead），使声音稍后到达扬声器时正好与正在记录的材料对齐。由于知道 playback 有 latency，入站 audio 可延迟相同量再次对齐。

第二条路在 timecode 与 transport synchronization 上有各种实现问题。Ardour 使用 read-ahead 补偿 latency。Ardour clock 显示的时间对应扬声器上听到的 audio 信号（而非 Ardour 从磁盘读取的位置）。

顺带一提，这也是许多项目从 timecode `01:00:00:00` 开始的原因之一：补偿 output latency 时 DAW 需从 session 开始之前读取数据，使 timecode 到达 `01:00:00:00` 时 audio 恰好及时到达输出。Ardour 能正确处理 `00:00:00:00` 情况，但可互操作的系统/软件/硬件未必行为一致。

1. Latency Compensation 与 Clock Sync

要实现 sample 精确的 timecode synchronization，需知道 audio 设置引入的 latency 并补偿。JACK 提供 API 让应用回答两问：从 port Ai/Bi 读取的数据到达 JACK 图边缘（capture）用了多久？写入 port Ao/Bo 的数据多久后到达 JACK 图边缘（playback）？但 JACK 无法知道计算机架构、操作系统与声卡引入的额外 latency。这些值由 JACK 命令行参数 -I 与 -O 指定，各系统不同但每个系统上恒定；在通用计算机上准确得知总（额外）latency 的唯一方法是测量。

1. 校准 JACK Latency

Linux DSP 专家 Fons Adriaensen 编写了工具 jack_delay，以亚 sample 精度精确测量闭合 audio 链的 round-trip latency。JACK 本身包含其变体 jack_iodelay，可测量系统总 latency、减去 JACK 已知 latency 并建议 jackd 的 audio-backend 参数值。

jack_delay/jack_iodelay 通过发出相当恼人的音调、经整条链往返后再捕获、测量相位差来高精度估计耗时。闭合 loop 的方式：把扬声器靠近麦克风（很少做，空气传播 latency 已知无需测量）；或用 patch cable 把 audio interface 输出连回输入（模拟或数字 loop，数字 loop 不含 AD/DA 转换器 latency）。

闭合 loop 后需：1) 以待测配置启动 jackd；2) 命令行启动 jack_delay；3) 在 jack ports 间建立连接闭合 loop；4) 在 mixer 调整 playback 与 capture 电平。

在 Linux 上 USB audio interface 的 latency 不恒定——重连、重启甚至 xrun 时可能变化（Linux USB 栈缓冲处理所致）。变通之法：每次 session 开始及每次 xrun 发生时重新校准 latency。

相关页面