MIDI Throughput, Latency & Jitter

Introduction

MIDI is a long established standard for transmitting messages about events that occur or should be triggered; typically in a musical context (hence Musical instrument digital interface). I say typically as MIDI has been used in various other contexts such as industrial machinery and lighting control. At it's core MIDI is a one way serial protocol.

Throughtput, Latency & Jitter

To begin with, I'll describe these three concepts in the abstract, and how they apply to MIDI.

Throughput

Throughput is a measure of the rate of data transmission; moreover if messages were transmitted as rapidly as possible, at what rate would they be received. Throughput is typically measure in bits per second (or some multiple, such as kilobits or megabits). Depending on the protocol not every bit transmitted forms a part of the message proper. In the case of traditional DIN MIDI, the bandwidth (the capacity of the link for throughput) is 31,250 bits per second (aka 31,250 baud, or 31.25 kbaud); the baud rate. includes any data used for safety checks and syncronization but the data transfer rate (often quoted in bytes per second) typically excludes such elements.

The MIDI protocol may be transmitted over various other carriers such as bluetooth (offering from 700 to 2000 kilobits per second) or USB (1 to 40,000 Megabits per second). It should therefore be clear that bluetooth and USB offer many times the requisite bandwidth (20 to over 1,000,000 times).

Latency

Latency is a measure of how long it takes for a message to be transmitted from the source to the destination. In practise latency can be considered the time taken from one device to indicate an event should occur, for the receiving device to begin making that event occur. In the case of a musical instrument this might be the time from pressing a key, to the sound being heard. In the real world there are many factors impacting this, but we will focus on the impact of the underlying transport medium: DIN MIDI, Bluetooth MIDI vs USB MIDI.

When transmitted over DIN (serial), a stop bit and start bit are used to indicate a data frame begins or ends. In the encoding used by MIDI, a message is 7 bits long but padded to 1 byte (8 bits) with a leading 0. The message is preceded with a start bit and ends with a stop bit. This means 10 bits need to be transmitted. Serial protocols have a clock running at the baud rate, meaning the first bit has to be aligned with that clock. Given a 31.25 kbaud connection, 10 bits takes 10.5/31250s = 336 us (microseconds, 10.5 as you, one average, will be half way through a 'bit send opportunity' when you wish to send a message). This means that the underlying transport used by MIDI introduces a minimum of 336 us of latency.

Bluetooth and USB are so much faster (at throughput) that you might imagine this latency would be tremendously reduced, but this is not correct. In particular these transports don't send data in a continuous stream, but rather send the data in larger packets which are sent or received on a certain schedule. The effective polling interval for bluetooth is on the order of 30ms, while USB polling intervals are typically 1ms (with 8ms being common on old devices). This means that on average, a bluetooth device experiences 15ms of messaging latency, and USB experiences 500us of latency. In other words, bluetooth necessarily experiences much higher latency than DIN MIDI, and USB MIDI is slightly, but not tremendously, worse.

Jitter

Jitter is a measure of the variability of latency; a way to think of it might be: given a series of equally spaced (in time) events, how equally spaced will the events on the destination be. One MIDI message type to which this is very relevant is MIDI Clock. MIDI represents the passage of musical time by sending 'clock ticks' at a rate of 24 per quarter note. This standardised rate allows for multiple devices to advance (musical) time dependent functions in sync. Depending on the context (e.g while playing back pre-recorded material), it may be possible to have relative playback between devices offset by some amount of time to compensate for latency: such compensation is not possible for jitter as it (necessarily) differs each time.

Since DIN MIDI has a fixed clock, the accuracy of a given event's onset is determined by that clock rate. In particular for a 31.25 kbaud connection, you expect an average of 'half a bit' worth of timing error: 0.5/31250 s = 16 us. When using a protocol like USB, in the worst case the jitter can equal the average latency: 500us; in other words the jitter experienced over USB MIDI could be 30x worse than that of DIN MIDI.

What Does This Mean

Throughput

While the USB and Bluetooth connection types are effectively unconstrained by bandwidth constraints, DIN MIDI is constrained. MIDI is a serial protocol meaning, for example, it is not possible to send multiple simultaneous events: the higher the bandwidth, the less time skew there is between events that should occur simultaneously. Consider that event simultaneity doesn't only apply per note, but for all events on that port, across all channels of all types (clock ticks, CCs etc). As an example a Note On event is 3 bytes, meaning 30 bits on the wire. This means a DIN port can handle around 1040 note on events per second; this means that there is at least a 1ms delay between coincident events; in other words, if I wanted to play a chord of 10 notes, there would be a 10ms delay between the transmission of the first and last note (assuming no other data on the wire).

The more data that is being transmitted (and interleaved) the greater this type of timing skew can become. Moreover on the 1 on a song you may have multiple CC being reset and multiple notes across multiple instruments being triggered, potentially causing tens of milliseconds relative delay between these events. In fact, if you are sending many notes and CCs on all channels on a single port simultaneously, it's possible to hit (or approach) the bandwidth limit which can make jitter very problematic.

Latency

As we've discussed, the minimum latency of DIN MIDI for a 1 byte message is 336us. For a message like a note on (3 bytes) you are looking at around a 1ms latency (limited by bandwidth). As we noted, USB has high bandwidth so the polling interval is the dominant factor. In the early days of USB 1, it wasn't uncommon for to have a polling interval of 8ms, this gave a 4ms average latency for any given event meaning it was invariably worse than native DIN MIDI. Almost any computer made in the last 15 years supports USB 2 high speed meaning 1ms polling interval and a 500ms average latency. In either case the minimum possible latency is comparable between transports (in the best case)

Jitter

As we know, jitter is a measure of variance of latency. In the absence of bandwidth constraints, we know a MIDI message can be timed to an accuracy of 0.5/31250s = 16us (average case). Consider also that devices receiving MIDI would have been designed with DIN MIDI bandwidth, latency and jitter values being accounted for. USB MIDI has a jitter matching the latency, in other words average jitter is on the order of 500us (i.e 30x greater). This headline "30x worse jitter" sounds bad, but in practise the jitter is often acceptable in either case.

Why Do People Complain About Jitter?

It's Not Jitter

First of all, a lot of people aren't entirely clear as to what impact latency vs jitter has. In particular often latency problems get referred to as jitter, and jitter problems get referred to as latency. This ambiguity muddies the water significantly. Similarly the actual perceived latency and jitter is a combination of the end to end chain from the source device 'deciding to send a message' and the receiving device 'receiving and handling the message and outputting sound' which in itself has latency and potentially jitter, irrespective of event transport.

Is It Actually a Problem

DIN MIDI

Where they are referring to jitter, often the complaints are not due to the user hearing the jitter but rather seeing it. The main place people see this is in when sending MIDI beat clock and looking at the BPM display on the receiving device. Moreover, for example, set a 120 BPM tempo on the source device and see the destination device report BPM varying from 119.9 to 120.1. When it shows a completely stable 120 BPM they declare the clock "rock solid". It's important to be aware that this variation reflects 'micro' timing errors as opposed to a 'macro' timing error (meaning the clocks will remain in gross sync indefinitely as opposed to drifting out of phase).

Let me address this first, in the context of DIN MIDI. We know that a single bit can be transmitted with a 16us average jitter. Let's consider the 120 BPM example; MIDI clock sends 24 ticks per quarter note and each tick is a one byte message. 60s / (120 bpm * 24 ticks) = 20.8 ms per beat. Lets look consider the worst case jitter, where one beat is almost one bit early and the next is almost 1 bit late (each being 32us). The time between ticks would therefore be 20.833ms +/- 32us * 2 = 20.769 or 20.89724*. Converting those to BPM we get 120.4 - 119.6. We can see that in the worst case we get a difference in the first decimal place. In reality, the inferred BPM isn't calculated per tick, but rather over a longer time scale. doubling the measured time, halves the impact of jitter on the number being displayed. Considering BPM up to 240 BPM, we'd expect 239.2 - 240.8 BPM meaning to reduce it to <0.05 we need to measure at least 0.8/0.05 16 intervals (about 160 ms). If we want enough stability to show a value to 2 decimal places we need the error below 0.8/0.005 = 160 intervals (about 1.6s). You can see that we are therefore trading stability of the displayed number against how quickly the displayed BPM will 'stabilize' (when the clock is starting or changes)

This is the cornerstone of the confusion. When the midi clock is being used to match the tempo of various 'free time' events (such as delay length) the actual delay time will track the stabilized value. For a sequencer however, this stabilization time is entirely irrelevant. This is because the events in the sequence are triggered by the arrival of the MIDI ticks (or their clock divisions). Moreover the timing is just as accurate from the first tick received. Note also that the stabilization on the BPM display may also be completely disjoint from any clock smoothing used in the synthesis engine (it usually reacts more quickly). Additionally, this variation in reported BPM does not reflect any sort of clock drift (a gradually increasing phase shift between the source and destination's sense of musical time).

USB MIDI

Applying the same analysis to USB MIDI we see a worst case jitter impact of a 240 BPM clock to be: 10.417ms per interval, so a worst case we see 9.917ms - 10.917ms gives 252.1 - 229 BPM. Assuming a DIN MIDI based device chooses 16 intervals this may show 239.3 - 240.8 BPM; in other words we will likely see significant variation in reported BPM. As with the DIN MIDI case, instability of reported BPM does not reflect the clock drifting: It reflects micro timing inaccuracy (less than 1ms per tick).

What Can I Do About It

As for what you can do about it, the answer is: ignore the BPM display on devices that are receiving MIDI clock: it does not reflect the accuracy of the clock but is instead just a convenience for the user. The next thing to do is realise that if you are using a computer, you are almost certainly using USB MIDI (whether the device has DIN Ports or not). The only exception is an internal PCI MIDI card, which wouldn't live on the USB host bus, but these are rarely seen nowadays. This means that USB MIDI is basically a fact of life for DAW users, and the perceived problems it causes tend to be greatly overstated; additionally solutions such as "getting an audio interface with DIN MIDI ports" aren't actually improving the situation at all. If you believe you have problems with MIDI throughput, latency or jitter then spend the time to try and localise the problem and make a change there. Computers have been the primary platform for music production for over 20 years: if it works for them, it should work for you too.