延时：一切数字设备的“原罪”

2022-11-26 19:15 作者:徐唯轶 0人读过 | 我要投稿

延时：一切数字设备的“原罪”
一次学会 MIDI 控制器

徐唯轶

建个系统来提质增效降本
专栏：工程师聊音乐设备

2022-11-26

延时定义
在这里是指按下键、或踩钉等触发部件后，开始触发 MIDI 指令，通过 MIDI 线传输，最后到达 MIDI 设备后，由最终 MIDI 响应的这一段时间。

延时，或者延迟，都随着混用已经变得不易区别。似乎用“延时”描述因设备本身机制导致的时间差，比较多点。“延迟”似乎用于指效果多点。

英文的“Delay”有用于指延迟效果，也有用于延时的这个概念。而“Latency”则一般会特指延时。当然，在英文的对比说明中，也是容易混，只是目前工程师较习惯“Latency”。

数字设备，延时是天性

我们的世界是“模拟”的，不管是看的，听的，还是接触的。“模拟”意味着极大的信息量，我们可以类比胶片拍照。

“数字”是我们对“模拟”世界的抽象定义，将主要信息、主要节点经过模数转换（ADC）变成 0、1 字节。然后通过数模转换（DAC），变成我们可接触的信息，如数字拍照。

胶片拍照在生活中已经离我们越来越远，但与数字拍照比，胶片在质量上有个无以伦比的优势：精度。胶片在后期，可以放大很多倍，而数字就有极限。比如我们的相机，从300万像素，500万，1000万，到现在1亿等等。胶片说：“都是小朋友，我只负责从外太空拍街景”。
数字暂时还无法100%取代模拟：

一方面提升精度就意味着数据量增长。如我们用手机拍视频，720p 一分钟可能几十m，4k 一分钟就可能1G。这对设备都是一种负担。或者说成本。

另一方面，人的感知存在边界，精度再大，如果不放大，对最终用户是无感的。正如壁纸只要和屏幕分辨率一致即可，再高的分辨率对最终结果不会有本质区别，或者说人享受不到分辨率增加的好处。

第三，就是我们讨论的延时。数据量越大，处理时间越长，这是常识。所以在声音领域，一方面是压缩数据量，即采样率在这么多年后，44.1kHz 还一直活跃着。另一方面提升芯片性能。

受限于数字的框架：数字处理时间，数字传输时间，数模转换时间这三大项，多数数字音频设备的设计基准为 5 ms（0.005 秒）。低于 5 ms 的设备就比较稀缺。
实战中，5 ms 根本不算事，甚至我们演奏时，自己的节奏就经常在 +/- 5 ms 范围波动。
但是数字设备经不起叠加，如 10 块 5 ms 效果器串联，结果就是 50 ms 延时，这就有不跟手的感觉了。

所以数字设备就是因为延时，对实时要求高的场合，如效果器，就不推荐多串联。通常 2-3 块是极限了。
特别注意，数字效果器最佳方案是综合效果器，因为有统筹规划，多个效果器可以数据并行的方式，控制整体延时仍然在 5 ms。

MIDI 延时三大来源：触发机制、合并机制、和传输速度

MIDI 是数字协议，所以天然具有数字设备的“原罪”——延时。

接下来将深挖什么在影响延时，影响有多大？

触发机制
触发是我们有意识，操作了设备，产生 MIDI 指令。在这过程中会存在一些不为人注意到的细节，导致“延时”。

一、踩钉策略
相对 MIDI 键盘、打击垫等设备，MIDI 控制器的踩钉，需要特别强调一下。

踩钉触发后的指令在设备内部是瞬发，然后在 OUT/THRU 口依据合并机制处理。

但部分为更好识别双踩，如 1号 + 2号钉同踩执行某功能时，就会倾向将踩钉触发形式，设定抬起为触发。如果踩下后有慢抬习惯的用户，就会人为造成延时。

注：在传统音乐教学，和直觉中，下压会定义成合拍，没有强调马上抬起。可参考指挥时，手下压合拍后，会习惯继续停留在下方位置。同样用脚打节拍时，脚也会习惯停留，不抬起，因为这很省力。

二、踏板策略

表情踏板在 EXP/CTRL 口使用时，是模拟信息，严格说每个变化都有值。精度高、速度快。
但表情踏板接入 MIDI 控制器后，就是要被转化成数字信号，然后传输出去。

MIDI 本身的速度不喜欢海量数据，就像数码相机在早期设备不发达的条件下，无法生产出1亿像素的相机一样，数据太大太多，会堵塞 MIDI 通道。

MIDI 识别踏板时，会“以一定间隔识别表情踏板"，即设计之初就设定了延时。实测中，就见过 10 ms，20 ms 级的产品。

而对应的 MIDI 响应设备，即效果器，需要设计渐变来平滑两个“台阶”样的 MIDI 指令。这也导致反复波动的操作值会略小于踏板的数据值。如手动哇音就会感觉效果不佳。

以应用效果来看，10 ms 是能用级。在和表情踏板直插效果器对比时，也能被感知到差别。对于哇音这类反复动作的效果差点味道，对于渐强音（Swell）这类单向动作的效果就可以满足使用了。

而 10ms 以上，如 20ms 级是无法使用的，会明显感觉不跟脚，出现“我已经回踩了，怎么效果还在增长”的感觉。

另外 10ms 以下，如 5ms 级，暂时未接触到，希望有哪位朋友推荐一下。

三、海量指令策略

少量指令基本是瞬发。5~6条指令这种，都是一次发送，压着 MIDI 传输速度走。

但大量指令时，就不一样了，会存在额外的延时。系统需要确保 IN 口的输入指令，会被即时的转发。如：6 条指令可能平均 0.9 ms/条，200 多条指令则平均 1.7 ms/条。

当然，这个海量仅仅相对 MIDI 1.0 协议，这是一份 1982 年的协议。

以上就是 MIDI 设备在触发层面可能产生的延时，我们暂定有个最大 10ms（踏板刷新率）的延时吧。

合并机制

当 MIDI 控制器从上游，如电脑，收到一组 MIDI 指令，正向下游，如效果器，转发时。

MIDI 控制器自己产生了一条指令，问：“怎么合并到一起？”

先上图：

指令 A、B、C 正愉快的依次输入

假设以极限 MIDI 1.0 速度，3,125 条/s，每条指令 0.32 ms/条。正从 MIDI 控制器的输入口，排队进入，然后再从输出口，被转发出去。

额外出现的指令 D

当 A 越过某判定点后，设备自身指令 D 触发了，且在 A 后，B 前。注意图中的蓝线为假定的判定点。

如果设备自身不断产生指令时，输入新指令，也是同样处理策略，不停将自身指令与转发指令对比到达判定点的时间。

输出 A、D、B、C

B、C 在原基础上，就被向后顺延了。

以基础的 0.32ms/条计算，就是延迟了 0.32ms。

如果考虑海量数据影响，延迟未知。

当然，还会有类似表情踏板的策略：将 A 视为缓冲单元，以 N ms 为一单元进行处理，每一单元处理 4 或 8 条指令，类似地铁、高铁的定时发车。那这个延时，就可能吓人了。

实战中，多是以一定的间隔处理，如 3ms，这个 3ms 发转发指令，下个 3ms 发自身指令。
过程中，如果转发指令只有 1 条，则会马上切换到自身指令，如果转发指令有很多条，则 3ms 内转发了若干指令。然后发自身指令，接下再转发收到指令。

目前只记得见过在海量数据下，转发存在 3 ms 的印象。是 MIDI 控制器一边不停发送，再由电脑发出指令，经 MIDI 控制器转发，检查同一指令的发出时间，和收到时间。

注意：将 MIDI 控制器发出指令固定在通道1，电脑发出指令固定在通道10以上（两位数），对查找指令比较有帮助。

此时，我们可以看出，在《转发：MIDI 设备必要的“小心机”》中，

"3、响应通道不转发：比如 MIDI 效果器接收通道1，则通道1的指令将不再转发，以减少 MIDI 指令流的信息量。但这种设计，会导致在 MIDI 检查时，无法确定效果器无动作时，是没收到 MIDI 指令，还是自身故障不执行。不是很推荐，通常是电脑类软件可考虑，因为方便监控数据，再针对性设计 MIDI 数据流方式。”

其设计原则就是为了减少指令，让后续 MIDI 设备减少负荷。

徐唯轶：转发：MIDI 设备必要的“小心机”：https://zhuanlan.zhihu.com/p/582980078

同样，我们暂定合并机制延时有 3ms 吧。