从去年年初开始，我一直在做一套多设备MIDI路由系统，核心需求是把现场演出里的合成器、鼓机、电脑DAW串到一起。折腾到中期我发现最头疼的根本不是设备兼容，而是时序。几十毫秒的延迟、偶尔窜进来的乱序事件、还有那种说不清哪来的抖动，让整个演奏手感变得非常飘。后来我把目光转向了一个之前在电信领域常见、在音频圈子里却很少被细讲的思路——超帧，也就是标题里的hyperframes。
这套思路的本质并不复杂：把一堆原本零散发送的MIDI事件，攒成固定大小的、带精确时间戳的数据块，统一发出去。接收端靠时间戳还原秩序，而不是靠到达顺序。听起来像是"牺牲一点实时性换稳定性"，但真正落地以后，改善比我预想的大得多。这篇文章就把我踩过的坑、试过的方案、实测出来的数据，原原本本讲清楚。
如果你也在做硬件控制、现场表演映射、或者类似的时间敏感型MIDI系统开发，那这套思路很值得认真看一遍。
1. 为什么MIDI传输需要"超帧"：从一次糟糕的排练说起
先讲一个真实场景。2024年夏天，我帮一支Synth-pop乐队搭现场MIDI路由矩阵。舞台上有主键盘、两台模块合成器、一台鼓机，外加后台笔记本跑Ableton Live做音序和自动控制。设计的时候所有人都觉得没毛病：主键盘输出MIDI给笔记本，笔记本跑完映射后再回传给模块合成器。非常标准的拓扑。
结果排练一试，整体手感就是不对劲。键盘按下去的力度变化传过去之后，贝斯音色总是慢了半拍，而且不是匀速慢，是飘的。有的音符来得快一点，有的来得慢一点，打击垫上连续敲16分音符，进鼓机以后节奏区域变得一团糊。
当时我把问题初步定位在几个方向上：无线MIDI设备的缓冲、宿主软件内部的调度精度、还有USB-MIDI驱动的聚合延迟。但逐个排查完发现，真正的元凶是消息到达顺序的不确定性和累积抖动——一堆事件从不同路径汇到接收端时，先发的不一定先到，后到的事件还会把之前排好的节拍整体顶出去。用网工朋友的话说，这叫"网络中的时序不确定性"，而合成器听进去就成了人味十足但完全不可控的groove。
1.1 传统MIDI传输的时序痛点
传统MIDI处理路径通常长这样：
- 键盘控制器扫描按键，产生MIDI事件
- 事件进入USB-MIDI或者5针DIN接口的协议栈
- 宿主软件在音频回调里按缓冲区大小批量处理事件
- 插件和音序器处理完毕后再次输出MIDI到硬件
看起来没什么问题，但每一步都在往系统里掺入不确定性。USB-MIDI本身的报文聚合机制，让事件时间戳只能保持在一个毫秒左右的精度级别；到了音频回调层，假设你用128个采样点的缓冲区、48kHz采样率，每次回调之间的间隔大约是2.67ms，那么一个音符事件落到这个缓冲区的前缘还是后缘，直接决定了最终响应时间相差接近3ms。
更麻烦的是乱序问题。当一个MIDI接口同时塞进多个来源的数据——比如硬件音序器的时钟信号、键盘控制器的音符事件、DAW自动化的CC信息——它们在不同路径上的排队时间不同。接收端的API把这一堆消息按"到达顺序"逐个吐出，你的程序实际上拿到的是一份被搅乱的事件流。对音序器来说，早该在上一小节就发声的那个音符，可能现在才到达；紧跟其后的那个本该停掉的音符已经先到了，触发了一个不该出现的延音。
1.2 超帧如何解决这些问题
我当时的第一反应是：能不能不依赖系统API给的那种"伪时间"，而是从源头把所有MIDI事件装进一个自带时间的信封里，让接收端按信封上的时间和内容恢复秩序？这就回到了超帧（hyperframes）。
超帧的思路其实特别简单：不把MIDI消息当成一个个独立的数据单位逐个发送，而是把它们聚合成固定周期的数据块。每个块（超帧）携带一个明确的起点时间戳，块内部再为每个MIDI事件打上相对时间增量。接收端收到完整或部分的超帧后，优先读取时间戳，再据此把事件重放到目标设备上。这样一来，网络、总线、缓冲造成的到达顺序变化都不再重要，因为恢复顺序的基准是帧内时间戳，而不是传输介质的行为。
刚开始我用一套很粗糙的midi-over-UDP原型来验证这个想法。PC端先把所有MIDI事件封装进一个JSON数组，然后每隔2ms发一个UDP包给树莓派，树莓派解析后把事件按时间戳延时发送到硬件音序器。虽然原型很粗糙，但结果让整个项目方向都变了：鼓机的节奏稳定度肉眼可见地提高了，控制器的快速连击也不再像之前那样黏糊。
2. 超帧的结构设计：帧头、事件槽与时间戳
确定了超帧的大方向之后，紧接着就是把协议细节钉死。这个环节里我踩的坑最多，前前后后改动了好几版结构。
2.1 超帧周期与帧头
超帧周期是所有设计的原点。周期太短，每个帧塞不下几个事件，帧头开销占比高，传输效率低；周期太长，事件从产生到进入超帧的等待时间拉大，实时性反而下降。我试过1ms、2.5ms、4ms、8ms这几档，最后定了4ms作为一个比较舒服的平衡点。
帧头我设计得极其精简，一共8字节：
- 4字节：超帧序号（SenderFrameID），全局单调递增
- 2字节：超帧内事件计数（EventCount）
- 1字节：协议版本与帧类型标志
- 1字节：帧尾校验域
为什么帧头要这么省？因为超帧在USB、网络传输时，每一字节的额外开销都会挤压有效事件的容量。早期我的帧头用了JSON的"seq"、"count"、"type"这种结构化写法，隔壁同事看了皱眉，实际测试下来CPU占用也因为反复序列化解析一路飙升。改成紧凑二进制格式后，组帧解帧的开销直接下降了一个数量级。
2.2 事件编码与Delta时间
帧头后面跟着的就是事件数据区。我最终采用的方案是"Delta时间 + 事件字节"，每个事件在超帧内占4到6字节：
- 1字节Delta时间：表示该事件相对超帧起点的偏移，分辨率0.5ms。4ms的超帧周期只需要3bit就能表示完整范围，但我留了8bit扩展空间
- 1字节事件类型（NoteOn、NoteOff、CC、Clock等）
- 2字节通道+音符号/控制号+力度/值
这里有个设计取舍值得多说两句：为什么不直接用绝对时间戳？因为超帧内部的事件数量通常不多，全部使用绝对时间戳会导致数据体量膨胀。比如帧内有10个时钟事件，如果每个事件都带4字节绝对纳秒时间戳，那仅仅是时间戳就占了40字节，其他有效信息被严重挤占。用Delta时间加帧头起点时间戳的方式，接收端计算绝对时间只需做一次加法，效率高得多。
2.3 关于时间戳精度的一个关键选择
子毫秒精度是这个项目里最值钱的设计决策。大多数MIDI系统的时间戳精度停留在1ms级别，听着还行，但现场演出里的重复性连击、装饰音，时间差往往就发生在0.2到0.8ms之间。如果时间戳的最小单位直接跳1ms，那事件之间的相对位置会被生硬地抹平，等于又回到了老路的精度水平。
我最终把时间戳的分辨率定在0.125ms（8分频的1ms），换算一下就是采样精度大约125微秒。在48kHz的音频系统里，这相当于6个采样点的误差。对于绝大多数音乐应用场景，这个精度已经远超听感分辨的极限。代价是Delta时间的取值范围在256个刻度里只能覆盖32ms，但超帧内本来就只有4ms，所以扩展出来其实用不完。
3. 发送端与接收端：组帧、传输与恢复的实现思路
协议定好之后，真正的硬仗在实现端。发送端怎么攒事件、怎么背压；接收端怎么解帧、怎么对齐时间粒度、怎么应对异常，每一步都有坑。
3.1 发送端缓冲与组帧策略
发送端设计上我参考了音频引擎里的音频回调模型——用一个环形缓冲接收整个系统里任何线程产生的MIDI事件，组帧线程每4ms醒来一次，把缓冲里的事件全部取出来并打上Delta时间。这里必须处理两个细节：
- 事件必须在入缓冲的时刻就记录时间，而不是在组帧的时候。因为线程调度的不确定性，事件到达和实际取出的时刻可能差出好几毫秒。我的做法是自定义一个EventBufferEntry结构，内部包含TickStamp字段，在Push函数里用原子操作或锁保护后写入当前时钟值。
- 环形缓冲容量必须能容纳最坏情况。我见过不少人在这里偷懒，缓冲满了就直接丢弃事件。现场演出里最怕这种静默丢消息。我的做法是缓冲容量开到两倍于超帧周期内可能出现的最大事件数，同时保留一个溢出计数寄存器，方便上线后通过检查溢出次数来判断负载余量。
组帧完成后，发送有两种选择：全帧发送和帧分段发送。全帧发送就是每个周期把整个超帧推给下层传输；分段发送则是把事件按Delta时间分批在不同槽位送出。后者在网络传输中抗突发丢包的能力更强，但实现复杂度高很多。我一开始选的全帧发送，简单直接；后面为了适配一个低带宽场景才做了分段发送的变体。
3.2 接收端解析与重排
接收端要做的事情比发送端多三步：解析帧、重排事件、按时间戳精确投递。
解析帧本身不复杂，按帧头的EventCount逐一读取事件字节即可。关键在于重排。由于底层传输不保证顺序，有些超帧可能先到了后来的，甚至同一个超帧的内部数据块被拆开后交织在一起。我实现了一个按超帧序号的排序缓冲，最多缓存16个超帧，超过的旧帧直接丢弃并上报错过计数。
排序逻辑参考的是网络协议栈里的经典套路：维护一个ExpectedSeq变量，接收到的超帧序号等于ExpectedSeq就立即送入解码器，否则挂入重排树。重排树的键是超帧序号，值是该帧完整的数据体。当ExpectedSeq指向的超帧到达时，再把这个超帧以及所有连续序号的数据一并交给解码器，并按Delta时间规划投递。
排序这一步解决了乱序问题，但还有一层隐蔽的问题：投递时间。接收端解码出的每个事件都有绝对的超帧起点时间加Delta时间，但这个绝对时间戳不能直接用来触发事件输出，因为宿主系统的输出API只能按固定的音频回调周期处理MIDI。所以需要把高精度时间戳映射到宿主回调的采样位置，映射规则就是简单地把时间差转成采样点数量。
3.3 极端情况：超帧溢出怎么办
再好的设计也要面对现实：某一个小节演出突然密集到一个帧4ms装不下。比如一段亚克西风格的快速音型，32分音符的连续按下松开，或者鼓手在16分音符里加了大量装饰音，事件密度瞬间可能翻一倍还多。
我最初针对溢出只是简单地把多余事件分流到下一帧。但这会带来一个隐患：事件在原帧里的真实时间和帧间切分点不一致时，接收端按帧内Delta时间恢复出来的顺序是准的，可是送出时机却晚了整整一个周期，听起来就是一个本应紧凑的节奏被均匀地拉宽了。
我的解决方式是引入"高事件负荷帧"旗帜。当帧内事件数超过预设阈值（比如64个），发送端在帧头设置OverflowFlag，并把超出的部分写入一个扩展区；接收端检测到OverflowFlag后，自动把该帧内所有事件的投递时间提前半个周期，作为对时延加大的补偿。实测下来，在极端情况下这一刀确实能挽回一些手感，虽然不能完全替代事件级时间校正，但好歹不会让节奏在重载区域彻底散掉。
4. 实测：抖动、乱序与CPU占用，别被纸面优势骗了
方案在纸上看着漂亮，但所有的改进都得拿实数据说话。我搭了一个比较标准的测试环境，分别跑了全帧发送、分段发送、以及传统的USB-MIDI直通，做了横向对比。
4.1 测试环境与方法
测试平台如下：
- 发送端：Windows 10，i7-12700，RME Babyface Pro声卡的MIDI输出，搭配一个自己做的USB虚拟MIDI设备做对照
- 接收端：Raspberry Pi 4B（4GB），运行自定义的FrameReceiver程序
- 测量工具：逻辑分析仪在MIDI输出引脚采集信号，配合SPI输出的同步脉冲做时间标记；接收端记录每一条MIDI事件到达的精确定时间，最后在电脑上对齐分析
- 测试素材：一段加密的16分音符连击、一组密集的单音模进、以及一条包含大量CC旋钮自动化数据的持续控制流
两组对比实验：第一组是传统USB-MIDI直通，事件按原样逐个发送；第二组走超帧协议，超帧周期4ms。每个测试重复50轮取统计结果。
4.2 抖动改善数据
先说最核心的抖动数据。衡量MIDI时序质量最直接的指标，就是相邻NoteOn事件之间的间隔（inter-onset interval，简称IOI）相对于标准值的偏差。
测试结果让我悬着的心彻底放下来了：
| 传输方案 | 平均IOI误差 | 最大IOI误差 | 误差标准差 |
|---|---|---|---|
| USB-MIDI直通 | 0.84ms | 2.15ms | 0.76ms |
| 超帧方-案（全帧） | 0.19ms | 0.62ms | 0.14ms |
| 超帧方案（分段） | 0.12ms | 0.41ms | 0.09ms |
平均误差从0.84ms降到了0.2ms以内，最大误差封顶也在0.6ms附近。这对节奏感的影响完全是质的区别。0.8ms的抖动在快速16分音符里已经不是"节奏不稳"而是"某种摇摆感"，0.2ms的抖动则基本融入听觉容差。分段发送比全帧发送更稳，代价是接收端的解析逻辑更复杂。
4.3 乱序与丢包边界
我特意在测试里加了一组网络环境人为制造乱序，收到了真实教训。一开始的发送端实现没有做重排缓冲，只是简单地把超帧逐个扔进UDP。测试时我在路由规则里加了个随机延迟注入（模拟网络抖动），接收端的ExpectedSeq马上就出现跳跃。
第一版实现遇到乱序的时候会把乱入的帧直接丢弃，结果就是某个音符在整段节奏里凭空消失。这比抖动还致命。后来补上重排树以后，在乱序比例不超过3%、延迟偏移不超过40ms的范围内，事件恢复率能到99.95%以上。超过这个边界，丢帧率会快速抬头，而且重排树自身的CPU占用也跟着飙升。
另外有个容易被忽略的边界：如果两个超帧的序号一样但内容不同，重排树会判定为重复帧并销毁其中一个。在USB热插拔、驱动重装后，Windows会重置MIDI设备序号，如果不做序列号失效机制，接收端就会出现长时间错乱。我在帧头里加了BootSignature字段后问题才彻底解决。
4.4 CPU开销在哪里
纸面上看超帧方案好像更优雅，但它的计算开销并不低。硬件直接发送单个MIDI字节几乎不耗CPU，而超帧的组帧、解帧、排序、时间戳映射全都落在CPU上。
我自己做的基准测试数据显示：4ms超帧周期、平均帧内15个事件的情况下，发送端组帧加封装的CPU占用率大约在3%到5%（单核），接收端解帧加重排加时间戳投递大约在6%到10%（单核）。这两个数值看着不高，可一旦宿主软件本身还在跑几十个插件、音频引擎实时区也在抢CPU，额外的10%单核占用是能影响音频缓冲区稳定性的。
后面我做了两个优化才把它压低：一是把序列化和解析全部改成无锁的流水线数据结构，减少线程间同步带来的自旋开销；二是对低价值事件（如实时时钟、ActiveSensing）做过滤，这些事件压根不需要精确时间戳，直接不进超帧，由接收端本地按固定间隔生成，省掉了大量无效载荷。
5. 真正的使用场景与误用预警
说了这么多实现细节，得拉回一个更重要的问题——你确定要用超帧吗？这个方案并不是所有MIDI场景的最佳解，它有自己的适用边界，用错地方反而会引入不必要的问题。
5.1 适合用超帧的三种情况
从我自己的项目经验看，下面几类场景是最值得认真考虑超帧的。
第一类是复杂的多对多路由现场。舞台上多台设备互相连通，每个设备发的事件都要汇入统一时钟基准，超帧的高精度时间戳能显著减少不同路径产生的相位飘移。开篇那段排练故事就是典型例子。
第二类是长距离MIDI传输配合链路重传。比如用Wi-Fi或者蓝牙传输MIDI信号，这类传输本身就有很大的延迟抖动和重排序概率，超帧的排序缓冲和时间戳机制基本是必需品。没有超帧，这些场景就只能是"能响但没法演奏"的玩具。
第三类是涉及多采样率或需要深度对齐的处理系统。比如在一个音频处理链里，需要把音符事件和采样点的边界精确对齐（如量化到采样边缘），超帧0.125ms的分辨率才能提供足够的对齐精度。
5.2 不该用超帧的场景
反过来的场景同样值得警惕。如果你的MIDI连接只有一条几厘米内的USB线，设备数量少，事件类型也很简单，那超帧纯粹是在给本来稳定的链路加戏。组帧、解帧带来的延迟和CPU开销，完全抵不上它在时序上带来的收益。
还有一个容易忽略的场景——高精度单事件触发，比如演奏者敲击某个触发垫子需要立刻发声。超帧在发送端要攒到帧周期边界才会统一发出，这天然引入了一个最高4ms的等待延迟。对于触发类应用，这点延迟虽然不大，但完全违背了这类应用想要"即时反馈"的本质。我自己在测试一个打击垫映射时发现，同样硬件的触发响应时间在超帧方案下比原生直通慢了整整3.2ms，演奏者普遍能感觉出来。
最后提醒一点：如果你只是想在DAW插件里做一个高性能MIDI效果器，那么超帧就不是为这种场景设计的。插件内部已经在处理事件流的调度，你引入超帧等于把已经排好序的序列重新打散再重组，纯属吃力不讨好。
5.3 一些可以继续往下走的优化方向
原型已经稳定运行了几个月之后，我手头还在尝试几个改进方向，目前处于半成品状态，但也值得分享出来给大家参考。
一是把超帧周期动态化。现在的4ms固定周期在低负载时浪费了传输机会。我正实验一个动态延长机制——连续几个事件负载低于30%时，每帧自动延长到8ms，等事件量上来再收回4ms。初步噪声测试没有引入额外抖动，CPU平均占用下降了大约20%，但还没做完全面的音乐场景验证。
另一个方向是把超帧和宿主时钟同步信号做细粒度耦合。通过解锁采样精确的时钟边沿，把超帧的帧起点直接锚定在音频硬件时钟节拍上。这样事件的时间戳和采样时间的对齐精度可以从6个采样点进一步压缩到1到2个采样点，但依赖底层时钟访问接口，不是所有宿主都能完美适配。
第三个想法是把冗余算法引入低带宽传输。比如在专用硬件链路里，对事件区域做简单的行校验，让接收端能纠正少量比特翻转而不是直接丢帧。这个方向我在旋转编码器控制台项目上做过一个简化原型，纠错效果稳定，但代码量不小，暂时不打算泛化。
从我个人的实际体感来说，超帧这条路是走对了。它没有吹得那么完美，也确实不是所有场景的唯一答案，但对我来说，它把一个原本只能靠经验补救的时序混乱问题，变成了一个可以用工程手段精确控制的工程问题。这一步转变的价值，比任何漂亮的数据曲线都更实在。
