Magazine Archive

Home -> Magazines -> Issues -> Articles in this issue -> View

MIDI Timing Delays

Software & Hardware Thrus

Article from Sound On Sound, March 1993

An occasional series which investigates some of the more technical aspects of MIDI. In this introductory article, Martin Russ measures some Thru delays.

Measurements can give the appearance of technical competence and superiority, but their interpretation is often misleading and ambiguous. The hi-fi world's obsession with specifications has produced amplifiers with bandwidths so wide that they can be used as radio transmitters and has squeezed astonishing performance out of the Compact Cassette, which was never intended to be anything more than a cheap and cheerful consumer recording medium when Philips introduced it.

MIDI delays are often blamed for all sorts of problems, both real and imagined. As with hi-fi, there seems to be a trend in hi-tech music towards more and more sophisticated measurement techniques. The time it takes for a MIDI instrument to make a sound in response to a Note On message is just one example of the sort of figure that is beginning to appear in reviews.

If reviewers mention it, then you can be sure that the manufacturers will soon quote it in adverts. So 'typical response time to MIDI note message' figures should start appearing in adverts in a few months time. Working out just what such figures mean is not at all straightforward, and some specialised hardware is required to actually make the measurements. Rather than wade in with a comparison of figures and a complicated explanation of what is going on, I intend to start with the simplest situation and work towards the complex — this also gives me time to perfect the test equipment. This is the first part of an on-going investigation which will report its results only when they are available — so don't expect part 2 next month!


Just about the simplest possible MIDI processing device is a Thru box. After that, things get very complicated very quickly. In rough order of complexity, you have: hardware Thrus; soft Thrus; mergers; mono-timbral synthesizers; multi-timbral synthesizers. This article deals with the first of these: hardware and software Thrus.

We must distinguish between hardware and software Thrus. The ordinary 'hardware' Thru socket is taken from the output of the opto-isolator at the MIDI In. The MIDI information has passed through the opto-isolator and is then connected directly to the driver gate for the Thru. This is not going to produce very much time delay — a few microseconds at most, perhaps.

In contrast, a software or 'soft thru', as provided by many sequencers, needs to pass the MIDI information through the opto-isolator, the UART and buffer, then process it in software and place it in the output buffer (see Figure 1). The outgoing UART then converts it back to serial and it is output by the MIDI Out driver gate.

Figure 1. This diagram shows a typical computer MIDI processing setup. The MIDI information arrives at the MIDI in socket and passes through the opto-isolator to the MIDI thru socket. The UART acts as the interface between the serial format used by MIDI and the parallel format used by the computer. After buffering in RAM, the information can then be processed by the computer software and placed back into ram for subsequent conversion back to serial format by the UART. The information then leaves from the MIDI out socket.

There are several places where time delays can occur:

The UARTs need to receive a complete serial byte before they can present it to the parallel data bus for reading by the microprocessor, which means a delay of at least 320 microseconds (one byte, plus start and stop bits) plus an extra half bits-worth of time (the UART always reads in the centre of each MIDI data bit), which makes a total of 336 microseconds (see Figure 2).

The microprocessor will take some time to respond to the UART, read the MIDI byte and store it in the input buffer: say four clock cycles. For an 8MHz 68000 processor (found in STs and Mac Classics), this is going to take about 50 microseconds. For simple interrupts where you are just moving a byte around between peripherals, a 68000 can service the interrupt and return to the main program very quickly.

Getting around to processing the MIDI byte (putting it into the output buffer) could take another eight clock cycles, which adds another 100 microseconds.

A further 50 microseconds transfers the byte from the buffer to the outgoing UART, which could take 12 microseconds or so to actually start outputting the packet.

Figure 2. It always takes at least 336 microseconds for a MIDI byte to pass through a UART. This is made up of 320 microseconds for the MIDI packet of start bit, MIDI byte and stop bit to arrive, and then an extra 16 microseconds for the UART to get into position to read each bit in the middle.

The total time taken to do all this is 336 + 50 + 100 + 50 + 12 = 548 microseconds, or just over half a millisecond. The human body seems to work on internal ticks which happen every 10 milliseconds or so, and so less than 1 millisecond of delay is unlikely to be noticed by most people with a casual listen. However, a busy processor might have longer delays in the input and output buffers, and could easily take much longer to process the byte, and so the figures could approach the point at which you could really begin to notice a delay.

Using a special serial processing chip like the 68302 or a DSP like the 56001 it would be possible to considerably reduce the processing time, since both of these chips are optimised for dealing rapidly with serial data. But remember that the initial 336 microseconds which it takes the UART to input the MIDI byte is fixed, and so the fastest that you could ever hope to process a MIDI byte is just over 336 microseconds. This 'absolute minimum' time also applies to mergers and response times of synthesizers.


Real world figures for opto-isolators and MIDI 'soft thrus' do not often appear in advertising material at the moment, so I made some measurements myself. I started with hardware. It takes a MIDI byte almost exactly 500 nanoseconds (half a microsecond) to travel from the In of my Atari ST to the Thru. Testing other MIDI Thrus gave some interesting results: Two of the devices tested did not produce any measurable delay! The rest of the hardware Thrus had timings consistent with their age: the old Yamaha equipment (TX7, FB01) obviously has slow (2 microsecond rise time?) opto-isolators, whilst the more recent equipment performs much better. The Roland figure suggests that they are using a high quality opto-isolator with a very wide bandwidth.

The V10 and MA36 do not have conventional MIDI Ins — the V10 is a Thru box, whilst the MA36 is a MIDI Analyser. Both devices merely buffer the MIDI signals and pass them to 'Thru' sockets; neither uses an opto-isolator. The delay in the buffers should thus be only a few tens of nanoseconds, but could not be measured with my current equipment.


For soft thrus, I tested several pieces of software on a 68000 8MHz 1MB Atari ST running TOS 1.4, and a 68030 20MHz 9MB Mac IIsi running System 7.0.1. I had to develop my own custom test rig for doing these measurements, since I know of no-one who makes any decent commercial measurement equipment for this type of MIDI testing. This test equipment will continue to be developed as I continue making measurements. The sequencers were powered up, left in their 'stopped' state, no song files were loaded, and so the only activity should be the 'soft thru'. (At this stage, I was not able to measure the delays with the sequencers active, ie. inputting and outputting MIDI information in addition to the soft thru under test. This will be the subject of a future article.)

As you might expect, the Mac's faster processor does produce lower figures overall, but the difference is not remarkable. Remember that 336μs (microseconds) is the absolute minimum time to get from the serial input of a UART to the parallel output. Taking this into account the Mac is about twice as fast, with one notable exception: my program on the ST. Using a high level language like HiSoft Basic might not be the normal route to blazing performance, but the 515μs time for a MIDI message to enter the ST's In, have its MIDI channel changed and then output again at the Out socket, is the fastest I measured. Subtracting the 336μs minimum time from 515μs gives 179μs for processing the MIDI information, which translates to a mere 14 clock ticks for an 8MHz 68000 processor.


Some of the delays through an otherwise quiescent sequencer were virtually constant, and these are shown as just minimum times, with no maximum value entered in the table. Others produced delays which varied on an apparently random basis. Trying to make valid measurements on such signals requires measurement facilities which were not available, and so I have presented just the maximum and minimum times which I observed. The average time seemed to be approximately mid-way between these times, but this could not be measured accurately.

The Thru times which are constant seem unusual at first, because you would expect that the time it takes for a microprocessor to go and get a byte, process it and then output it again, would vary a little bit each time. But with the processor clock ticking every 12.5μs for the 8MHz 68000 example, the delays caused by even 10 ticks variation are going to be only 125μs, just over ten percent of the time delay variation that I measured.

So, a typical hardware Thru has a delay of about half a microsecond, whereas a 'soft thru' introduces a delay of about a millisecond.

Figure 3. The effect of a random delay on repetitive events. Some events end up closer together, others become further apart.


The ratio of 2000 to one in time delay shows the advantage of using real 'hardware' Thrus rather than relying on software. More importantly, if the random variations in the output of MIDI messages are also reflected in the sequencer outputs under normal operation, then the sequencer is introducing timing errors into the output which were not present in the original recording (see Figure 3).

To put this into context, remember that a single MIDI byte takes 320μs, and so a running status Note On message occupies at least 640μs. Many sequencers have timing resolutions of 480ppqn or better, and this translates to approximately one pulse every millisecond at 120bpm with 4/4 bars. So a random time delay in a Thru of about a millisecond is thus slightly longer than the time it takes for a Note On message, and about the same as the time between ticks. What this boils down to is the rather remarkable thought that unless the random variation is less than 1 millisecond, timing resolutions of more than about 480 ppqn are not worth having.


Looking at the results so far, further investigations with sequencers actually working under real conditions instead of just Thru'ing the MIDI should prove to be very interesting. However, getting those measurements will be rather tricky — so be patient!


In ->Thru (nanoseconds)
Philip Rees V10 Thru box not measurable
Studiomaster MA36 Analyser not measurable
Roland CM32L 200
Yamaha SY99 300
Kawai K5 350
Atari ST Computer 500
Yamaha TX7 4000


Atari ST with TOS 1.4 (68000 @ 8MHz)

Software Minimum μs Maximum μs
Dr.T RealTime V1.11 1100
PG Music Band-in-a-Box V5.0 1300 4000
Microdeal Concerto V1.1 800 3000
Steinberg Cubase Lite V1.0 1100
M Russ CHAN04.PRG V0.4 515


Mac IIsi with System 7.0.1 (68030 @ 20MHz)

Software Minimum μs Maximum μs
Opcode Vision (OMS) V1.32A 875
Opcode EZVision V1.0 775
Passport Master Tracks 4 V4.02 716 1700
Dr. T Beyond V1.5 600
Steinberg Cubase V1.8 775 850


The timings mentioned in this article use three units which may be new to you: nanoseconds, microseconds and milliseconds.

Scientists, technicians and engineers use a system of units where all the names are based around ratios of one thousand to one. For measuring length the basic unit is the metre, whilst for small objects you deal with millimetres (one thousand millimetres make one metre) and for large distances you work with kilometres (a thousand metres equal one kilometre).

In this article we are working with time measurements. The basic unit of time is the second:

A millisecond (ms) is one thousandth of a second.
A microsecond (μs) is one millionth of a second.
A nanosecond (ns) is one thousand millionth of a second.

Looking at this the other way around:

There are 1000 nanoseconds in a microsecond.
There are 1000 microseconds in a millisecond.
There are 1000 milliseconds in a second.


How did I work out that '480ppqn' is just about equivalent to '1 pulse every millisecond'? Here's how:

480ppqn implies a bar with four quarter notes, which means a rate of 1920 pulses per bar (4 x 480 = 1920).

At 120bpm, there are two beats per second (120/60 seconds), and so a 4-beat bar lasts 2 seconds (two lots of 2 beats).

So 1920 pulses in 2 seconds works out at one pulse approximately every millisecond (1920/2 = 960 pulses in 1 second).

One thousand pulses in one second = a thousandth of a second per pulse, and a millisecond is one thousandth of a second.

That's all there is to it!

More with this topic

Browse by Topic:


Previous Article in this issue

Hammer Time

Next article in this issue

Sampling Techniques

Publisher: Sound On Sound - SOS Publications Ltd.
The contents of this magazine are re-published here with the kind permission of SOS Publications Ltd.

The current copyright owner/s of this content may differ from the originally published copyright notice.
More details on copyright ownership...


Sound On Sound - Mar 1993



Feature by Martin Russ

Previous article in this issue:

> Hammer Time

Next article in this issue:

> Sampling Techniques

Help Support The Things You Love

mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.

If you value this resource, you can support this project - it really helps!

Donations for July 2024
Issues donated this month: 14

New issues that have been donated or scanned for us this month.

Funds donated this month: £20.00

All donations and support are gratefully appreciated - thank you.

Magazines Needed - Can You Help?

Do you have any of these magazine issues?

> See all issues we need

If so, and you can donate, lend or scan them to help complete our archive, please get in touch via the Contribute page - thanks!

Please Contribute to mu:zines by supplying magazines, scanning or donating funds. Thanks!

Monetary donations go towards site running costs, and the occasional coffee for me if there's anything left over!

Small Print

Terms of usePrivacy