Timing and Jitter Midi (2001)
Luca Pilla

It is good to clarify what the terms of the research are. For timing we intend the transmission of one event at a pre-arranged time, precise and wanted. As far as the MIDI standard is concerned there are some hardware limits (every byte has a duration of 320 microseconds), that make a total time of 960 microseconds for one event of note (formed by 3 bytes), namely almost a millisecond after the byte transmission has been sent by the computer. The Midi transmission is serial, and so, in the same cable, a second event of note at the same time is expected after about 2 ms after the beginning of the transmission. The seriality of the Midi or the sequencer (we'll soon try to make this concept clear) is then also shown in the use of more Midi channels in the same wire or the same port. Transmitting 16 channels on the same cable means introducing a delay of 16 ms for the events transmitted on the 16th channel if compared to the times of the first channel, like a case of an accord of 16 notes where each note has its own midi channel. With very few exceptions, this delay cannot be eliminated but dividing the channels in different Midi ports. The jitter influences the time of transmission, namely a temporal swing when the Midi byte transmission occurs. It's caused by a number of factors that were so far thought to be responsibility of the Midi interface, of the computer and computer-related aspects. We'll see that a remarkable part of the jitter is in reality caused by the sequencer and by the interface driver, and this is already a very important discovery to minimise the jitter. A further element can influence both the timing and the jitter. It's the use of the USB standard to link the Mac with its interface. The subject, in theory, has been very much debated on the previous issue of SM Strumenti musicali (Musical intruments). In practice the best timing doesn't necessarily coincide with the best times of transmission, as some might think, but on the contrary with lower jitter rates. In fact, if it is possible to make up for a constant delay in the transmission of data, on the other hand it's impossible to compensate a value which keeps on swinging in a rather big temporal window, with apparent randomness. The best solution to optimise the Midi timing should be an interface with identical periods of transmission next to the zero for every Midi Out port which are being used at the same time, and a transmission with the jitter rate which should be as little as possible. Our tests will tell you if this ideal interface exists or not.

AMT, LTB, MTS AND ADVERTISING

Latency is a hidden phenomenon of the software and the operating system, it can come up as a delay, and it's especially inconstant and it is shown as Midi Jitter, with some exceptions. The introduction of sequencers capable of handling audio, video and Midi implies different problems of latency definable according to the priority with which the sequencer associates the reproduction of audio, video or Midi recording. For this reason systems like MTS of Motu have been created. They should equalise the priority of audio, video and MIDI in order to avoid that one of the 3 parts go out of sync, even for a few milliseconds. This information, for MTS in particular, unfortunately arrived pretty late, when the tests had already been finished and the interfaces given back. So it wasn't possible to prove the validity of these methods that, we say it again, have been introduced to improve the MIDI timing, anyway without underlining in what kind of conditions. While Motu answered by clarifying how and when MTS can be activated, we haven't received interesting answers by Emagic, apart from what has already been advertised. Steinberg's LTB system, for Mac, was at an elaboration stage as the tests took place. None of the 3 producers revealed anything new about timing rates of their respective interfaces, overlooking the results we obtained from the tests.

THE JITTER AND POLYPHONY

The most surprising and interesting surprise coming from the analysis of the data is the handling of polyphony by the sequencer or the interface. How can a sequencer send 128 notes, placed in parallel, we mean at the very same time, to the MIDI interface? And how important is the MIDI interface when it comes to handling and sorting out the notes to the channels and ports? Moreover, which is the most important tool between the interface and the sequencer? These questions wouldn't have come up if we hadn't measured the times of Cubase and of the multiport interfaces of Midiman, who also has a good partnership with Steinberg. Cubase has showed a strange behaviour compared to Logic and Performer: it's insensitive when it comes to notes of polyphony, breaking all the times measured on all interfaces. So if with Logic and Performer it is easy to find times higher than 30 ms in the test of maximum load of polyphony, with Cubase 12 ms are never exceeded (in the worst possible situation). How come is that possible? Cubase seems to be adopting a polyphony-handling algorithm, which exploits a temporal window of transmission of data much bigger than Logic and Performer. This way it seems able to distribute the 128 notes in a time of about 4 milliseconds compared to the reduced times of Logic and Performer. In the easiest test (P1/C1), this window is apparent and can be higher than 4 milliseconds. By looking at the oscilloscope with Cubase in phase of reproduction, the note is never sent out at the same time as the previous one, even though the biggest number of notes is between the minimum and maximum value. In the case of Logic and Performer the position of the following note is very predictable. If what has been said so far is clear, Cubase minimises the times of transmission of the data, by increasing the jitter even by 10 times, compared to the average rates of Logic and Performer. Reducing the temporal window for the transmission of data, on the other hand, implies having a smaller jitter but a bigger seriality for the transmission of data, which is highlighted in longer delays. The jitter also grows when the USB connection gets introduced against the serial one. For single data we invite you to take a look at the tables. What makes this subject even more intriguing lives at the other end of the stick: also the drivers or the hardware of the MIDI interface are "guilty" for the handling of the polyphony. The Midiman Midisport 8 x 8 interface demonstrates that polyphony can be sorted out at the base, whatever type of sequencer is in use, thanks to the test of maximum load and to the 7 tests dedicated to the single ports. There's only one exception, who knows why (similar algorithms?), the Midisport 8 x 8 and Cubasepair, which show the highest values in the test, even if totally below Logic and Performer. Whatever the situation, the polyphony-handling algorithm is the ultimate responsible both for the delay and the MIDI jitter. At the moment there is no a definitive solution to contain both the delay and the jitter which, from our measurements, are in inverse proportion between each other. An increase of the delay means a reduction of the jitter and viceversa. Anyway it isn't easy to reach a univocal conclusion: from one point of view it is better to have a minimum jitter, so that it is possible to have a bigger predictability; from another one the reduced work of the interface allows bigger availability in the case of the use of a MIDI controller in real time . Once again, these data have to be valued case by case by the professional looking for the perfect timing.



THE TEST
In order to measure a delay we need an absolute time which we should refer to. In this case the synchronisation of a 30-per-second-frame SMPTE LC code has been chosen with the sequencer and therefore with the following comparison of the times recorded with the MIDI Out of the interface considered with the SMPTE values. The test preparation phase coincided with the recording of a 30 fps code, on an audio track, and with a 30 Hz sinusoidal wave on a second track, written on a CD. In order to the form of sinusoidal wave as source for the oscilloscope and then as visual reference of the single frame, the synchronisation of the 0 of the wave form happened, with the end of the sync word of the LTC code. In this breaker differences of phase can be noticed if the quality of the D/A converters of the CD player isn't really good (and this is what happened in our case). Every cycle of the waveform matches a single frame and our measurements have had an accuracy of 200 microseconds. In order to synchronise the MIDI events as well, with a duration of a 16th, at 30 fps, multiple values of time of the value determined by the following formula have been used: ( (30/16)*60 bpm =112.5 bpm. The sequence of MIDI events for the test is a pattern of notes of a quantized sixteenth, repeated for 15 minutes and for all the MIDI channels and ports available on the interface. To add further precision, we checked that the same pattern formed by MIDI controllers wasn't reproduced in a different way by the sequencers, and actually no differences were noticed. The use of a pattern where at the same sixteenth there can be, in vertical, even 128 notes allows highlighting the kind of transmission adopted by the sequencer and by the interface, and the handling of the polyphony and the MIDI flow skills. A further test is based on the transmission of dumps of sys-ex to verify a possible polling of the USB transmission. The interface measurement signal is directly picked up by the MIDI Out in order to avoid further delays due to MIDI information elaboration of any audio module.

HARDWARE AND SOFTWARE FOR THE TEST

The base system is an Apple G4 500 DP with 1.5 GB RAM and 2 USB independent ports, a Megawolf Romolus 4-port serial PCI board, a 2 serial-port 28x USB Keyspan adapter, g4 Port of Griffin Technology for the use of the modem as serial port. The operating system is a standard installation, with original CDs, of Mac OS 9.0.4 with 500DP with OMS 2.3.8, FreeMIDI 1.45 and USB Device Extension 1.4.5. Deltron produces all the MIDI wires that were used for the test. The version of the MIDI interfaces is reported in their descriptions. The sequencers are Logic Audio Platinum 4.7, Steinberg Cubase VST 32 5.0 and Motu Digital Performer 2.72. The LTC/MTC converters are Motu Digital TimePiece, Motu MTP AV, Motu MIDI Express and Logic Unitor 8 MK II. In the sequence of tests all the MIDI interfaces that are currently available on the market (Italy included) were used, including for reference the Apple MIDI interface, excluding all the products that associate MIDI and audio on USB. In order to convoy the MIDI signal to the oscilloscope, without interrupting the loop, a simple switch was used, described and produced by Hinton Instruments, in England. The reason why a Mac was thought for the test is due to the fact that it's impossible to find a platform for PC that can be considered standard among all the PCs sold, therefore the repetitiveness of the tests can only be guaranteed by the Mac.


THE UNCERTAINTY OF MTC

MTC is the abbreviation of MIDI Time Code, a protocol that allows transferring the temporal information of the SMPTE code into the MIDI standard. Although the MIDI standard declares that the transmission volume occupied by MTC isn't that relevant, a first test verified how the contemporary transmission of MTC and MIDI events with the same MIDI interface remarkably worsens the delay and the jitter in transmission. A direct consequence was the use of the LTC/MTC converter on a different port from the interface submitted to the test of measurement, thanks to the independent double USB port on G4 and to the 4 serial ports on Romulus. What invalidates the measurement of a single event delay most is the intrinsic inaccuracy of these converters, verified with the oscilloscope and suggested by one of the main experts in Italy as far as SMPTE and synchronisation are concerned. Expanding on this subject a bit more, it was clear that it's not possible to totally rely on the SMPTE synchronisation via MTC because there are no data or measurements about the delay in the audio signal elaboration in MTC bytes and there is no compensation of the emitted MTC value relating to it. A last test also showed something that should not have happened. Digital Performer shows better times when synchronisation occurs through USB rather than the serial mode. If the synchronisation with MTP AV USB takes place through a serial transmission or through Digital Time Piece on serial, times rise by about 1.5 ms. The same happened with MIDI Express USB, with serial port, forcing all the battery of tests for DP to be re-arranged. On the contrary Cubase and Logic seem to prefer the MTC code transmission on serial, with better times of 1 ms than the USB transmission. Anyway we used the transmission and the sync converter that we thought to be more convenient for the single sequencer. DP works better with Motu MTP AV on USB, Cubase and Logic improve their performances with Motu Digital Timepiece on serial. The problem of synchronisation inaccuracy has never been thrashed out and apparently there are different performances and implementations from the MIDI standard. A further problem appeared with Logic. The first measurements showed acceptable times, with a good 27 ms on the first channel of the first MIDI port. Considering the times gathered with Cubase and Performer, the temporal position of the MIDI bytes was compatible with an advance of 1/4 frame, corresponding to 8.3 milliseconds. By using the offset page of the synchronisation on Logic a software bug was found: when the value gets modified into milliseconds or quarters of frame, Logic doesn't work according to plans. It's actually enough to visualise the value in bits to realise that the quarter of frame or the milliseconds introduced don't match the real value in bits. The bit offset, however, has always worked out. Logic divides the frame into 80 bits, so the offset has always been +20 bits. Speculatively we could say Logic has a delay of 3/4 frames, but it's more malicious to think that the advance allows catching up on the times of reaction of the timbre modules. Just hypothesis.
The lack of absolute certainty about the work of LTC/MTC converters that were used has to make us consider the measurement obtained with the test P1C1 unimportant. The time included between 0 and the best value gathered among all the interfaces in the P1C1 test could be strongly conditioned by the LTC/MTC converter or by an imprecise MTC implementation. However the difference in the delays measured on the ports following the first one, still considering the best time obtained with the P1C1 test, are values of certainty which highlight the real behaviour of the interface, the MIDI driver and the sequencer. As we can easily understand from the tables, the best times with the P1C1 test are below one millisecond, therefore it is impossible to state that the LTC/MTC converters are more dangerous as far as imprecision is concerned. These times are extremely small, and they shouldn't be able to influence the result of the synchronisation or the music performance in a radical way. To sum it up it is possible to say that the real values of delays of the MIDI interface in question should be corrected in defect by deducting the minimum value measured among all the interfaces in the P1C1 test from all the results. However, in order not to mix the reader up and for reasons concerning the clarity of the data we have preferred to indicate the absolute values measured on the oscilloscope.


THE BATTERY OF TESTS
Now that the borders of these measurements are clear, it's time to getting into the details of the tests and to explain their usefulness. The three main tables regard the three sequencers considered, with the same interfaces tried for each, and in some cases with further tests due to the presence of peculiar features, like the use of freeMIDI for Performer or the direct connection to the sequencer like the Emagic interfaces with Logic. You won't find, due to space reasons, the measurements carried out with Keyspan and Griffin adapters, for which a specific box is reserved.

P1C1
It's the most immediate test: It consists in measuring the delay against the sinusoidal wave zero, which regards the starting point of the frame, in basal conditions. Only one track being played on the first port should be the most favourable condition. It's interesting to notice the track being played isn't a critical parameter for the sequencer. As a matter of fact there are no differences, in this test, if the first track is played rather than the 128th. As we widely said before, the value of delay that was measured directly depends on the quality of the converter LTC/MTC and so the result cannot be but indicative and it has to be related to the following tests.


16
Sixteen tracks are played on the first available MIDI port and another track is played on the last available port where the MIDI signal for the measurement of time is taken from. In this case we can observe an increase of the delay due to the grade of seriality of the sequencer or the interface driver. The speed of data transmission is also tested. The test is very interesting for anyone who has a simple 2-independent-port interface and can exploit it at its best.


32
It's like the previous test but this time we have 16 channels being played on the first port, 16 more being played on the second and finally the 33rd channel reproduced on the last available port on the interface. The above considerations are still valid, here more patent because of an increase of the MIDI load.


Poly
It's the most crucial test because it demands the reproduction of the maximum number of channels for each port but the last one, on which there's only one channel in reproduction, which is the same channel, referred to for the measurement. The type of connection, the sequencer and the driver of the interface make the difference. With this test it's possible to highlight non-declared limits, where the timing of the events gets irreparably lost after a certain number of channels in reproduction (the maximum number of channels that allow maintaining the timing is reported in brackets in the table), the appearance of evident jitter and the transmission speed between serial and USB. Of course parallels have to be made for interfaces with the same number of ports.


P1
It coincides with a series of tests that show the differences of transmission when more ports on the same interface are used, and whose results are extremely interesting for the professional. In fact it is clear that, few interfaces apart, adding one port to play another track gives a delay that can easily made up for. This result bucks the trend against the professionalism of multiport interfaces. This test demands the reproduction of just one track on the first port and the measurement of the delay of just one track being reproduced on a port succeeding the first one. We need to observe the delay that is measured depends on the number of active ports and not on the position of the port with reference to the first one.


P2
This test is identical to the previous one but with a track being reproduced on the first port and another one on the second, measuring the third on the last port.

P3, p4, p5, p6, p7
They are the continuation of the two previous tests. An increasing number of ports are set to reproduce (the number next to the "p" tells us the number of ports in reproduction with just one track yet again, measuring the delays on the last port with a track being reproduced.


Details
The tables show information related to the number of available ports on the interface, for Performer the use of FreeMIDI too, the kind of connection and the sync source, namely the LTC/MTC converter.


THE RESULTS
Now we are ready to comment and untangle the quantity of data so far submitted. We'll never be tired of repeating that if you have never had MIDI timing problems, or if you're simply among those professionals who claim the best quality, these results could actually be considered unimportant, overlooking the cultural and discussion aspects. In order to make things easy, we have divided the comments according to the type of sequencer and the kind of interface.


EMAGIC LOGIC AUDIO PLATINUM
It's Midiman 8 x 8 to hold court in each test of timing but not those of jitter, with the same limits and values that we'll find in DP. The result with Emagic USB interfaces and the direct connection to Logic is interesting. We achieved it by eliminating the OMS control that shows results 0.2 milliseconds better than the same interface used via OMS. MIDI jitter values are acceptable, higher than DP but lower than Cubase, so that it could offset those of Midiman 8 x 8 USB. It was also predictable that the most disappointing results are about the use of the 1 MHz serial connection where Express XT with serial ports suffers serious delays and loss of timing above the 45th MIDI channel.
All the 4,2, or 1-port USB interfaces proved to be very fast, in particular mt-4 which is the most efficient in the group along with the simple dumb interface on serial, which however can't catch up with the times of the P1C1 test the USB counterpart achieved. MicroExpress showed a few problems, especially on serial transmission. Logic Audio Platinum exploits the USB transmission efficiently and also shows a jitter whose assessment directly depends on the kind of work that has to be completed. We would like to remind you that in the version that was used in the test there was a bug in the SMPTE synchronisation page, so the P1C1 values can't be considered categorically.


MOTU DIGITAL PERFORMER

The best results were obtained by using FreeMIDI in OMS compatibility and the surprise was Midiman Midisport 8x8 with USB transmission that maintained very low times both in the polyphony load and transmission tests on several ports. To counterbalance these results is the MIDI jitter with 6.6 MS difference in the polyphony load, the MIDI driver that literally takes hold of OMS and a control panel that has a lot of compatibility problems under 9.0.4. We notice the mediocre results of MTP AV USB when the 1 MHz serial transmission is exploited (and by the way this is not good in any situation). Times get back to the average ones as soon as it is used in Fast mode or via USB. In consequence of MTP AV USB there are the Express XT performances, only with serial port which doesn't allow the Fast transmission. The absence of this mode of transmission is highlighted in the limit of MIDI channels beyond which the MIDI timing is lost: MTP AV USB, Express XT/USB, Express XT and MicroExpress used in 1 MHz serial connection have limits and very important polyphony times in regard to expectations and USB versions. As far as P1C1 transmission speed is concerned, the gold medal has to be awarded to Unitor 8 MK II under OMS, followed by AMT 8 in the 16-channel polyphony test on one port. If I had to decide which interface DP should be matched with I would choose FastLane USB without a doubt, because it is the most efficient USB MIDI interface in the whole battery of tests. A couple of these simple interfaces are better than any 4-port interface, and the Mt-4 is certainly the best compromise. It is also interesting the Yamaha UX-256 which has the best times in the single-port tests. Thumbs down for MicroExpress, the cinderella of the group. Without doubt, if we leave out FastLane USB under FreeMIDI, the American sequencer is a champion in limiting the MIDI jitter and gives its best performances when a FreeMidi driver is used, if available, although the most efficient interfaces belong to the OMS category. Thanks to the helpfulness of the Italian distributor and their related assistance (in the person of Massimo Cherubini), Motu clarified the use and the usefulness of the MTS technology: it only goes into action when DP is reproducing audio and/ or video files, assuring the correct timing of the MIDI data. If DP exploits just the MIDI part there won't be any differences between an interface with MTS and one without it. Unfortunately this information didn't arrive before August, when the test had already been finished and all the interfaces given back, so it's never been possible to verify this.



STEINBERG CUBASE VST 5
It's Midiman Midisport 8x8 with USB connection that rules and would also be the ideal choice if it wasn't for the time obtained on the maximum polyphony load with a jitter of 10 ms. Very fast in the P1C1 test are the Unitor interfaces 8 MK II and AMT -8 with USB connection. Predictable the results on 1 MHz serial with MTP AV that struggles even in the tests of polyphony, limiting the channels of polyphony without losing timing in company with Express XT and Micro Express, again on 1 MHz serial.
A confirmation as far as speed is concerned arrives from two and four-port interfaces on USB, with very similar values among themselves. MT4 and Midisport 4 x 4 stand out. The USB-2-MIDI interface is very fast, even if it's under OMS. Cubase certainly prefers the USB transmission rather than the serial one. It's been clear all along that Cubase uses a polyphony algorithm which is different from DP and LAP. And this implies very little times (also with a maximum load of polyphony) and a remarkable increase of the MIDI jitter. The explanation is apparent: Cubase distributes the single MIDI bytes according to this algorithm, in a temporal space defined by the jitter window, avoiding the congestion of the transmission band and releasing in fact the MIDI interface from handling the data getting in. This behaviour has to be carefully assessed. It's certainly positive if we consider the absence of bottlenecks in the polyphony or in very high loads, with not very powerful interfaces, too. On the contrary the professional could find a 5 ms jitter unacceptable.