ORIGINAL: Jim Wright

Hi Jon,

What kinds of MIDI interfaces are you testing?
USB 1.0 protocols uses a 1 millisecond 'frame rate', so under best-case circumstances, events will be quantized to a 1-millisecond window. USB 2.x supports micro-frames (0.125 millisecond rate), so in theory quantizing effects could be smaller.

If you're testing MIDI I/O on a Mac, using a non-timestamping USB MIDI interface, I would expect the lower jitter bound to be around 1 millisecond, more or less. That doesn't mean you'll get such tight timing in practice - that's just the best you could expect if the rest of the software was working with very close tolerances..

Of course, under Windows, many apps probably still use the 'Windows multimedia timer' (MMT) - which has a nominal accuracy of 1-millisecond, but is not very precise (ticks can be delayed for lots of reasons, and then 'delayed' ticks can be sent in a clump - speaking imprecisely here). An app that uses the MMT for timing and USB MIDI for MIDI I/O will generally exhibit worse jitter than an app that uses the MMT and a PCI-based card for MIDI I/O. (Reason: jitter effects are cumulative).

- Jim

Hi Jim

I have used many interfaces over the years but the best ones and quickest have been the Lynx One and an ensoniq Audiopci(which is much like a SB). Both are very quick and stable. Yes usb stinks though you can get respectable interfaces sometimes but usually not. Yes with timestamping you can get things better but that to me is a work around for os issues and you have to get specific hardware and use specific software. I'm measuring the midi data itself coming out of the interface so again it is not exactly as it might appear. The sequencer is trying to keep the data in tempo so it has to overcompensate to do it. If the an event was delayed say 1ms then at some point that has to be made up by pushing an event 2ms. Things would actually be better if after the 1ms delay the sequencer simply played in tempo from then on rather than accelerating to make up the difference. At least that is what I'm seeing in the raw data coming out of the interface. It is very consistent and correlates well if you simultaneously record it into another sequencer and compare. Here is another good example of timing tests that deal with the raw midi data.
http://www.cs.hmc.edu/~bthom/publications/NIME_04.pdf
Good stuff and somewhat similar to what I'm doing though I'm focusing on the sequencer playback itself.

Jon

ORIGINAL: Jim Wright

>> transfer of Note On/Off command takes from 0,64 to 0,96 ms via MIDI and from 0,64 to 2,464 ms via DCB....

DCB ?

- Jim

thats an old propietary standard similar to midi that was used by roland in the days of the juno/jupiter era...
actually it didnt make it against midi...

cheers

ORIGINAL: info@tomflair.com

ORIGINAL: Jim Wright

>> transfer of Note On/Off command takes from 0,64 to 0,96 ms via MIDI and from 0,64 to 2,464 ms via DCB....

DCB ?

- Jim

thats an old propietary standard similar to midi that was used by roland in the days of the juno/jupiter era...
actually it didnt make it against midi...

cheers

Oh yes, I'd forgotten about that one.
There was also an "Oberheim System" interface (pre-MIDI) that used parallel rather than serial data transfer.
The Oberheim interface was much faster than MIDI DIN (I don't have numbers handy), but had several drawbacks:

• It was not ground isolated (MIDI DIN uses opto isolators). In practice, it was easy to blow out the interface electronics at a gig, if electrical grounds were at all funky. Roland DCB seems likely to have the same problem, based on the connector pinout I just Googled.
  
• The parallel interface circuitry cost a lot more than a MIDI DIN interface. Since MIDI was intended for use in products with street pricing as low as $200 or less (1982 dollars), the cost of the parallel interface was prohibitive.

A couple of points about MIDI DIN and Note On/Off messages.

• The times given (0,64 to 0,96 ms) are correct for sending a 2-byte (Running status) or 3-byte message over MIDI DIN.
  
• Those times don't include overhead for MIDI processing in a typical computer. Add at least another 1-2 milliseconds for 'modern' workstations / operating systems.
  
• Dedicated hardware boxes can certainly do better. I built hardware in the late 80's that could process MIDI with no more than 0.4 milliseconds added latency (for smart MIDI filtering, etc), using an 8 bit micro and no Windows or OS X overhead. The Akai MPC products have pretty low-jitter MIDI capture/playback, AFAIK (some of the Roland Microcomposers may also be good; I'm not sure).
  
• USB MIDI (in 2000, when I tested it), had latencies in the range (5,15 ms to 12,65 ms) under typical load conditions. Current USB MIDI is better (according to tests by Martin Walker/Sound On Sound), but still not as good as good PCI-based MIDI interfaces.

- Jim

ORIGINAL: Jim Wright

ORIGINAL: info@tomflair.com

ORIGINAL: Jim Wright

>> transfer of Note On/Off command takes from 0,64 to 0,96 ms via MIDI and from 0,64 to 2,464 ms via DCB....

DCB ?

- Jim

thats an old propietary standard similar to midi that was used by roland in the days of the juno/jupiter era...
actually it didnt make it against midi...

cheers

Oh yes, I'd forgotten about that one.
There was also an "Oberheim System" interface (pre-MIDI) that used parallel rather than serial data transfer.
The Oberheim interface was much faster than MIDI DIN (I don't have numbers handy), but had several drawbacks:

• It was not ground isolated (MIDI DIN uses opto isolators). In practice, it was easy to blow out the interface electronics at a gig, if electrical grounds were at all funky. Roland DCB seems likely to have the same problem, based on the connector pinout I just Googled.
  
• The parallel interface circuitry cost a lot more than a MIDI DIN interface. Since MIDI was intended for use in products with street pricing as low as $200 or less (1982 dollars), the cost of the parallel interface was prohibitive.

A couple of points about MIDI DIN and Note On/Off messages.

• The times given (0,64 to 0,96 ms) are correct for sending a 2-byte (Running status) or 3-byte message over MIDI DIN.
  
• Those times don't include overhead for MIDI processing in a typical computer. Add at least another 1-2 milliseconds for 'modern' workstations / operating systems.
  
• Dedicated hardware boxes can certainly do better. I built hardware in the late 80's that could process MIDI with no more than 0.4 milliseconds added latency (for smart MIDI filtering, etc), using an 8 bit micro and no Windows or OS X overhead. The Akai MPC products have pretty low-jitter MIDI capture/playback, AFAIK (some of the Roland Microcomposers may also be good; I'm not sure).
  
• USB MIDI (in 2000, when I tested it), had latencies in the range (5,15 ms to 12,65 ms) under typical load conditions. Current USB MIDI is better (according to tests by Martin Walker/Sound On Sound), but still not as good as good PCI-based MIDI interfaces.

- Jim

thanks for the additional facts - usb ..to 12ms...wow that scares me !
but i wouldnt ever use a usb midinterface anyway....maybe i should bring my atari st520 back from the garage :-)
anyway i just got a yamaha rx7 and i will use it to sync (via midi2cv&roland sync) my old synths and the 808 ....i am really looking forward to jam with 4-5 synced units without having even to powwr up my pc ... hahaha !!!

>> thanks for the additional facts - usb ..to 12ms...wow that scares me !

It's the jitter (7.5 ms peak) that was really bad, more than the latency (around 8 ms average).
However, these measurements are for first-generation USB interfaces (circa 2000).

Recent USB interfaces (Edirol UM-550, Emu 0404-USB) are a fair bit better.
For example, Martin Walker measured the MIDI latency of the Emu 0404-USB as 1.7 ms. He didn't report jitter; I'd guess jitter is in the 1-3 ms range.
Still not as good as a PCI-based interface (e.g. my Emu 1820M), but probably usable.

Also, these numbers do not incude any jitter contributions from OS timers (used to timestamp captured MIDI, and play it back).
For example, assume the MIDI interface has inherent jitter of 2 ms. Now, use OS timers with 1 ms accuracy to capture and playback MIDI.
Jitter for MIDI Capture will be 2 ms (interface) +1 ms (OS timer) == 3 milliseconds (total jitter on "live" MIDI data recorded by your sequence).
Now, play back the MIDI data. Additional jitter will be 1 ms (OS timer) + 2 ms (MIDI interface) == 3 milliseconds total additional jitter for playback.
However - the actual total jitter imposed on the original live performance will be 6 milliseconds in this case, because capture ('recording') and playback jitter are additive (3 ms capture + 3 ms playback = 6 ms total peak jitter).

6 ms jitter is quite audible if you have good ears, especially against something like a complex percussive background.

All of these numbers assume your system is tuned, drivers are up to date, and nothing (network drivers, anti-virus, etc) is messing up the basic timing accuracy of your system.

All of this is true for any DAW (sequencer) software running on a Mac or Windows PC. The numbers may vary a bit, but the principles are the same.
Since MIDI capture and playback go through MIDI interfaces (that add some amount of jitter) and MIDI events are timestamped using OS timers (that also exhibit some amount of jitter), you end up with less-than-perfect playback of a live performance. Since the live performance is played back through a similar process (using OS timer and MIDI interface) - more jitter is added during playback. I have no particular reason to think that Sonar is any worse (or any better) than any other Windows sequencer. Mac sequencers might provide better timing accuracy (Core Audio has some nice sequencer-timing support, and some MOTU interfaces claim to provide 0.3 ms timestamping accuracy), but I haven't tested them.

This is why (IMHO) the performance of each individual piece in the chain has to be really good, in order to produce an end result that is musically adequate.

- Jim

I have been researching some midi latency issues I'm having and came across this excellent old thread.  Anyone have any idea where things are with regards to midi jitter and latency in 2015 running under Windows 7?  Directsound is mentioned in this thread as having the ability to timestamp midi events.  This doesn't seem to be applicable, at least for Win 7 64bit which I'm using.  Do most modern audio interfaces perform time stamping of the midi events now?  Does Sonar X3 recognize these time stamps?  The Emu 1820M is mentioned in this thread at least a couple of times by Jim Wright as having good jitter and latency performance.  I'm still using this interface, but it doesn't have anything other than beta drivers for Win 7.  I wonder if its performance is still high in Win 7...
Dan

I was running an E-MU 1820m at the time of this thread as well. It did have excellent MIDI performance, but the x64 beta driver proved very unstable for me, and a hardware fault eventually forced me to dump it. I'm now back to using my MOTU MIDI Express XT USB which is much slower, but jitter continues to be a non-issue for me now as it was at the time.

Dan_E10
I have been researching some midi latency issues I'm having and came across this excellent old thread.  Anyone have any idea where things are with regards to midi jitter and latency in 2015 running under Windows 7?  Directsound is mentioned in this thread as having the ability to timestamp midi events.  This doesn't seem to be applicable, at least for Win 7 64bit which I'm using.  Do most modern audio interfaces perform time stamping of the midi events now?  Does Sonar X3 recognize these time stamps?  The Emu 1820M is mentioned in this thread at least a couple of times by Jim Wright as having good jitter and latency performance.  I'm still using this interface, but it doesn't have anything other than beta drivers for Win 7.  I wonder if its performance is still high in Win 7...
Dan

I use an Emu 1616m PCMCIA laptop system to play BFD2 "live" on a Windows 7 64-bit laptop. It is imminently playable, with no jitter issues to speak of. Very gratifying and quite fun to play. Sounds fantastic, too.

There is a well-documented jitter bug in Sonar.

Documented well where? :)