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!

MIDI THRUS

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.

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.

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.

MEASUREMENTS

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.

SOFTWARE THRUS

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.

ANALYSIS

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.

WHAT IF...

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.

FUTURE WORK

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!