Part 5:

MIDI Delays

There have been myths about MIDI delays ever since MIDI was introduced and it is important to understand the various causes and how they may be avoided.

Hardware Delays

These are normally small and are really a pulse width distortion of a few microseconds. They are caused by connecting several pieces of equipment together in a daisy chain using the MIDI Thru ports. When MIDI was first introduced there were two types of opto-isolator available: slow and cheap or fast and expensive. Needless to say the cheap ones were often used and such equipment is incapable of more than three Thru connections. The slow opto's transistor has a different turn on and turn off time so that at each successive stage the data is distorted until it becomes unrecognisable by the next receiver. The price of opto-isolators has come down a lot, helped by the large use in MIDI equipment, and the slow grades are only now used in the cheapest equipment. All opto-isolators have similar pinouts so it may be possible to upgrade some equipment.

Software Delays

These arise from different causes and may range from 0.35ms to 100ms, the latter is an extreme example, but illustrates how bad poorly designed software has been known to be. Worse still some delays vary considerably.

Bottleneck Delays are caused by trying to pump too much data down a MIDI cable. It is not realistic to attempt to pump 16 channels of data down one cable simultaneously. That implies a 15ms delay for something. When merging data, if two notes occur at the same time one will be forced 1ms behind the other. Sharing a cable with MIDI Timecode may cause problems as the data can only fit in the gaps between Quarter Frame messages. These delays may be minimised by reorganising the routing so that less data is on each cable. Share the load.

Latency Delays: sometimes the equipment is busy with another task when the MIDI data is received and does not respond immediately. Personal computers always have screen and disk tasks as a priority over communications so will never perform as well as a dedicated piece of hardware. Some are worse than others...

Processing Delays: any device that receives MIDI data, alters it in some way, and then retransmits it causes a delay of at least 0.32ms plus the actual processing time. If the device has to receive a complete MIDI message before deciding what to transmit, e.g. velocity remapping, then the total delay may exceed 1ms. Software based patching systems that incorporate merging often introduce delays and may not function at all under heavy traffic conditions. If possible MIDI data processing should be done by the end receiving device or not in real time at all, otherwise processors should only be patched in as and when required.

MultiPort Delays are probably the worst sort because they are caused by all of the above as well as an architectural flaw! The so called "fast" interfaces transmit data between a computer serial port and an external "multiport" interface, but only at a rate x2 or x4 that of normal MIDI. This creates an illusion of working, but under busy conditions or with a large number of ports fails dismally. The larger the system the worse the performance.

These devices have recently moved over to USB which although another factor of 4 faster still does not solve the problem. Clock rate is not the same thing as data throughput.

There is no substitute for multiple MIDI ports directly on the computer bus and a hardware routing system.

Scanning Delays All equipment controls are scanned by a microprocessor, some faster than others. It is common to scan knobs at about 10ms intervals with some special controls, e.g. Pitchbend, faster at about 5ms. Scanning too fast may generate too much data which then causes a further delay as the receiving device tries to keep up. A keyboard player automatically compensates for the scanning delay (you don't actually know when the switch contact is detected), but MIDI guitars and audio to MIDI triggers causes problems because any delay is immediately obvious. Analogue synthesizers and MIDI to CV converters usually employ a scanning system to update and refresh their outputs. Some are much better than others, beware of manufacturers that do not specify these times.

Scheduling Delays: most computer based sequencers operate on an internal time interval, usually around 2.5ms. If the tempo is accurate to several decimal places this technique is undoubtably used and any MIDI event that misses one interval has to wait until the next causing a quantisation dependent on how busy the sequencer is. One very popular piece of software is incapable of getting a note within a couple of its own intervals from the clock that caused it!

Tell the software producer that accurate timing is more important than flashy graphics.

Inefficiency Delays: it is possible to pack MIDI bytes stop bit to start bit without a gap, but some equipment is just too poorly designed to manage it. The 6850 UART was used a lot in early designs even though it was obsolete and in the Atari ST computer it was even made to share an interrupt with the keyboard. Not that PCs are any better, the MPU-401 is also 6850 based and is normally used as a dumb UART. Cheap gadgets often use microcontrollers at slow clock rates to save power.

If it's in a plastic box, has phantom powering via MIDI or has an external wall wart PSU it doesn't belong in a professional installation.

How to Measure MIDI Delays

Delays may easily be measured with a dual beam oscilloscope and a couple of cable adapters. If moulded MIDI cables are used it is difficult to get a probe onto the wires and as MIDI is a current loop no voltage will be seen until the loop is connected.

A simple adapter can be made from two DIN sockets by wiring pins 2, 4 and 5 together and this is placed inline between a MIDI Out and a MIDI In. To look at a MIDI Out without a load it is even simpler, just short pins 4 and 5 together and connect the probe to that point.

Make up two adapters and place before the MIDI In of the Device Under Test (DUT) and after the MIDI Out. Provide a regular source of MIDI Data like a sequencer looping at a fast tempo. Trigger the oscilloscope off the negative edge of the MIDI In signal and measure the difference to the same point of the MIDI Out signal.

The trace illustrated above shows a MIDI Out delayed by 0.6ms from the MIDI In. As the device does not read the data until the end of the first byte this breaks down into 0.32ms transmission time (which is constant) plus 0.28ms processing time. If the processing time varies there will be a spread of delays on the second trace and if that exceeds 0.5ms this will start to effect critical timings in rhythmic music.

The delay shown is quite respectable, but be prepared for an order of magnitude worse!