The difference between PCI/PCIe and USB/FireWire MIDI is below 0.5 ms with RME products. We do a special transfer for MIDI data that gives unusually low values for USB/FireWire.

Just make sure to use the "High Performance" power-profile on Windows, because the other profiles (including the default "Balanced") affect MIDI performance negatively!

Timur - thanks for the tip. I'll keep it in mind for my Windows tests - if I eventually get to that. I've actually conducted all of this under Mac OS and plan to keep doing so. But I will be curious about how W7 performs in this department. I'd typically expect W7 to have a slight edge over Mac OS *after a lot of tweaking*. But by all means, please let me know if you know that preformance edge to be significant! That might completely change my testing schedule...

vinark - thank you too for the tips! My test setup is down, and has been so for a long time. I had conducted these tests around March 2012. But I have detailed data and I did preliminarily compare the UFX MIDI ins v. the Axiom USB. My initial results are a vastly mixed bag. There are sooo many variables here and I had to end my spring testing sessions prematurely so I only have limited data ATM. The initial data suggests that not only VIs but DAWs may matter too:

1. Axiom USB > Logic 9.1.6 @ UFX 32 Buffer 96K > Klopfgeist > Keypress to Audio :: 7.83ms AVG | 1.71ms jitter range
2. Axiom USB > PTHD 10.1.1 @ UFX 64 Buffer 96K > Structure > Keypress to Audio ::  8.65ms AVG | 3.33ms jitter range

The buffer setting bump from 32 (Logic) to 64 (UFX) only makes a difference of about 0.33ms in audio output latency. So Logic + Klopfgeist seems to have a slight edge in AVG at 0.49ms (0.82-0.33), but a more significant edge in jiiter: 1.62ms drop. From a preformance standpoint jitter might be at least as important as average latency; the more the jitter, the less consistent the response to real time performance!

OK. Now, let's compare result (2) with the results below:

3. Axiom MIDI > MOTU micro xpress USB > PTHD 10.1.1 @ UFX 64 Buffer 96K > Structure > Keypress to Audio :: 11.24ms AVG | 2.54ms jitter range
4. Axiom MIDI > UFX USB > PTHD 10.1.1 @ UFX 64 Buffer 96K > Structure > Keypress to Audio :: 11.82ms AVG | 3.93ms jitter range

Wow. So maybe PTHD is giving some special access to the Axiom since M-Audio is Avid? That's unlikely though as the Axiom uses vanilla Core MIDI AFAIK. Go figure No.1!

Now, let's compare result (1) with the result below!
5. Axiom MIDI > UFX USB > Logic 9.1.6 @ UFX 32 Buffer 96K > Klopfgeist > Keypress to Audio :: 7.34ms AVG | 3.07ms jitter range

OK. So with Logic, UFX MIDI inputs perform slightly faster (0.49ms) than Axiom USB, but the jitter range is almost doubled! Go figure No.2!

Oiiii.

This is all so messed up. I will have to put my testing setup back up and conduct many more tests before I will be able to get a grip on this issue really.

This is why, before I resumed my tests, I wanted to hear from RME staff whether PCI MIDI makes a substantial difference. I need to minimize and optimize the variables as much as I can…

Any ideas / thoughts / comments re these results?

vinark - I see what you're saying re guitar v. keys performances. I might actually be in agreement with that but I'll have to see for myself…

Thanks all!
Derin.

Timur, thanks for posting these.

As far as I understand, these are pure interface latency numbers. This would be a nice piece of puzzle to have. If I had this for my systems, I would be able to subtract both this and audio latencies to arrive at a ballpark triggering latency figure...

What tool did you use to do the testing? I would want to try it here for my setup too under W7. I vaguely remember that there might be a similar testing tool on the Mac side but I might be wrong. Actually, I'm thinking, wouldn't I be testing a similar thing if I were to use a loopback cable and trigger a VI MIDI channel in a DAW with another VI MIDI channel, and measure the difference between the source and the target?

Now, had I also the theoretical latencies measured via a tool like what you used, I could then start comparing DAW performances too maybe; by comparing actual in-the-DAW MIDI loopback latency to the theoretical one measured outside...

Does that make sense?

Do you happen to have a similar set of measurements for the Fireface line too? (Not trying to second guess MC here; just curious about actual numbers!

---! Oi, just realized that Timur actually did already provide measurements for UFX-USB in his above post - sorry about that!

Matthias, I can see why the wow comment may have seemed odd. I think I haven't made it clear enough.

The wow was not about the comparison between results (3) and (4). Those are, as you pointed out, very close. The wow was about the comparison between them and result (2), where Axiom USB does 8,65ms; whereas the MOTU and the UFX cluster around 11,5ms. That's why I speculated that the Axiom may have had some special access to PTHD.

It is plenty clear to me that a lot is happening outside of the interface. What I am trying to do is, disect the whole thing and arrive at its pieces, so I can get a better grip on what I'm dealing with.

Speaking of which, when you say 1ms with Windows MIDI test, I presume that that value includes a Windows MIDI driver, right? If so, Core MIDI may behave differently. So is there a comparable tool that you use or know of, with which I can test pure interface performance on the Mac? Having access to the numeric value of pure interface performace on the Mac would allow us to compare platform efficiency in terms of MIDI I/O...

I have not yet investigated how timestamping works. So thanks for reminding me of that.

But I'm thinking, for what I'm trying to measure it matters only partially. Here's how and what I'm measuring;

I have 3 data points:
1. The audio recording of the keypress itself. I place a mic at the MIDI keyboard and hit the key as hard as I can to generate a clear attack.
2. The recorded MIDI event.
3. The audio recording of the VI that was triggered.

If you look at this strategy, you'll realize that where the MIDI note is placed is not relevant at the time of performance. It will only become relevant at the time of playback and that is actually very relevant indeed. But my first focus is on performance latency. I first want to be able to perform with a MIDI instrument with an as immediate and consistent feeling as I can. But timestamping definitely needs to be undestood and examined for playback of performances, especially if you're not capturing the audio of such performances.

Thanks!

Excuse to chime in, but I have to admit: Cool!
The only way to get the feel of computer algorithms....:-)

> is that in real time they usually feel inconsistent and especially rhythmically quite awkward

Reminds me of old times:

http://www.rme-audio.de/english/techinfo/lola_latec.htm

Low jitter in return for slightly higher latency may even be by design in Cubase. For example I know that Ableton Live does this (or at least advertised to do so).

I used Miditest.

http://earthvegaconnection.com/evc/products/miditest/

Just to mention it: MIDI can transport 781.25 notes (on + off) per second. As a result there is a lag of 0.64 ms between two notes that are being played together (note on), not taking jitter into account.

I once tested various of my MIDI interfaces for maximum bandwidth on Windows and OS X. All but the M-Audio 2496 (PCI) failed, but RME was very quick to fix this in their drivers (and introduced DirectMusic MIDI shortly afterwards). While I was testing this I noticed that on both Windows and OS X (Leopard) shared the same weakness that drags the performance of a good working MIDI interface/driver down if any other MIDI interface/driver cannot deliver good bandwidth.

Since Lion this seems to have been solved on the OS X side, didn't test for Windows (8) yet, but will do once I find time.

Yes it is all serial, one bandwith for all. but those midi notes per second might be in running status. Look it up! To late to explain it now. Midi running status

I think you find this a very interesting read:
http://www.midi.org/aboutmidi/tut_midimusicsynth.php

Try this: http://www.expert-sleepers.co.uk/index_ … e-es-4.php

Having a poorly implemented driver installed or even using it at low bandwidth is not a problem. But once you saturate the "poor" bandwidth of such a driver it drags down the bandwidth of all other drivers in the system.

Both with and without loop-back via DAW. I created tracks of 65 note on+off events each (=1/12 of maximum MIDI bandwidth) and ran MIDI Sync over another interface (trying both physical and virtual/software). Then duplicated tracks until the DAW started to react erratically, mostly showing in tempo/bpm dropping when the DAW was ran as MIDI Sync slave (but in some cases also audio, CPU load, etc).

As far as I remember the loop-back, or rather the input, wasn't the culprit (Input and Output get their full MIDI bandwidth individually). Some of my USB midi devices (Novation Remote SL, Korg PadKontrol) could not deliver full MIDI bandwidth (or even a good fraction of that) via their outputs without causing the DAW suffer. Both my M-Audio 2496 and later the FF 400 were able to run at full MIDI bandwidth for as long as none of the "poorly implemented" drivers were run over their choke limit at the same time.

Especially virtual/software implementations are practically only limited by CPU and artificial limits (like implementing 3125 bytes/s per channel maximum albeit it isn't really necessary). To give you an idea: I ran two separate instances of Ableton Live as Midi Time Code (MTC) slave to a software via virtual/software MIDI cables. All three applications ran on the same machine concurrently. Starting playback of both Live instances via MTC lead to _sample-accurate_ timing, which was easily assessed by running the output of one Live instance phase-inverted (=nullified sum when mixing both instances to a single channel-pair via Totalmix).

At least you are fine as far as total bandwidth is concerned. But I did not test for jitter back then, because I simply decided to keep the problematic device out of the chain when necessary (or in the case of the Remote SL to run it via DIN MIDI to the FF 400 instead of using its USB MIDI driver).

The biggest issue modern computers still face when they have to handle is not the irrelevantly low bandwidth of 1980's MIDI protocol. The fact that MIDI has to handle lots of small events in near real-time is the problem that modern hardware and especially software still chokes on. Modern SSD drives can deliver maximum bandwidth of well over 500 mb/s, but once you start transferring many small random blocks you cab see performance drop down to less than 20 mb/s.

The bandwidth is per MIDI cable/plug for _everything_ that runs over that single cable (regardless of what events, what MIDI channel, SYSEX or whatever). Each cable gets that full bandwidth, so you can run several MIDI ports at full bandwidth simultaneously, unless one driver plays foul and drags all the others down. I have to retest this all with later incarnations of Windows 7/8 and OS X.

That's good to know. At least it doesn't hurt right off the bat…

I'm not sure I fully understand how you conducted the test. Yet I'm not going to ask you for details and waste your time - at least not now, when I know I'm not going to be running the test myself anytime soon. But may I PM you if it ever came to that?

That's another reassuring bit of information! Grateful that you shared that with us! So if you use proper virtual MIDI implementation, you don't even need Rewire, at least not for syncing multiple DAWs to each other. Did you use the IAC bus on the Mac side? What did you use for Windows? Also, very clever use of Totalmix right there - I'll keep that in mind!

Hmm. But isn't it the case that when you have more bandwidth (and thus greater resolution), you're dividing time into ever smaller moments so that jitter and timing variations, even if they still exist, become irrelevantly small? If we were reporting MIDI latency and jitter in microseconds even, wouldn't both become totally irrelevant for performance purposes? Also for MTC applications; wouldn't having a greater resolution allow for greater sync accuracy even over external, hardware to hardware connections? I agree that bandwidth is irrelevant in the case of the number of events, unless there's a lot of activity on multiple channels simultaneously - like in your loopback tests. Aside from that, though, stirpped down to its essentials, isn't timing accuracy about the only thing that a protocol like MIDI has to handle properly? The timing of note on/offs, sustains, bends etc? And wouldn't that task become much easier to carry out accurately, if there was greater resolution?

I suspect that the choking you mentioned happens when VIs come into play; translating and "assembling" those MIDI commands into audio. The more MIDI events that need "translation", the more tax on sound engines and the CPUs that need to run those. And that, I agree, has nothing to do with MIDI bandwidth itself.

Aaah, how did I miss that! Of course! Note offs have to be accounted for as well. Thanks for clarifying that.

That's just crap (great visual presentation of the problem BTW!). That just brings back that feeling I get whenever I delve deep into MIDI. That your best bet with MIDI is always to stay within the confines of one DAW and I/O setup so as to not complicate things any further. Heck, ideally, just treat MIDI instruments as real instruments and capture the audio of your performances so as to not take any chances. Perform better, not edit better! Then what you heard while you were performing will be perfectly preserved in audio however f'd up your MIDI setup may be. If you insist you want a MIDI sequencing workstation and not just an instrument, the task becomes, then, test out DAW / IO / Keyboard combos, find the one that works best and then stick to it all the way. This may mean that you might not get all those MIDI tools you're used to; heck you may even have to switch OS platforms or have to learn a totally foreign DAW (I for one am curious about Digital Performer). But it seems that for the sake of accuracy and reliability, sacrifices have to be made in the case of MIDI.

Sorry for the rant

I will get back to our discussion re chokes and bandwidth.

I want to give that some more thought...

Timur - here's why I'm having trouble following your logic through to the end.

Given 31,250 bps speed of MIDI, 3125 ticks per second means 10 bits per 0.32ms. That includes the start and stop bits (1+1) and the clock byte (8).

Now, let's think about 2496 audio.

24 bits per sample @ 96,000 samples per second means: 24 x 96,000 = 2,304,000 bits per second.

2,304,000 / 1,000 = 2,304 bits per ms.

2,304 * 0.32 = 737.28 bits per 0.32ms.

737.28 / 10 = 73.728

So within the same amount of time that passes for one MIDI tick, one 2496 audio stream requires roughly 74 times the amount of data to be moved. Now, I am not sure how audio interfaces handle multiple streams, but I'm guessing that each channel of audio stream adds one more count of the same amount of data. If that's correct, a stereo 2496 channel would require 737.28 * 2 = 1,474.56 bits of data to be handled per 0.32ms, and on and on.

Following your logic of, isn't a single 2496 audio channel infinitely more complex and smaller compared to a single MIDI channel; so that something this small should wreak more havoc than it does presently?

Also, for my UFX, I remember measuring 51 samples of DSP Round-Trip Latency (RTL) in and out of Totalmix at 2496. That comes to about 0.53ms RTL. Totalmix handles this without a hiccup for all its channels. Of course this efficiency comes from its dedicated and real time nature as you might put it. But this is testimony to the fact that even if not 0.32 ms, proper processing will handle 0.53 ms just fine. And if it were only a single data stream that needed handling, as is the case with MIDI, I bet that number could go even below 0.32 ms. But I'm guessing that that DSP chip is probably weaker in raw power than even a lowly single core Pentium 4 CPU.

Talking about a P4 CPU, let's do another exercise. (And I'm going out on a limb here - I'm no engineer)

Take a single core 3 GHz P4. That thing runs at 3,000,000,000 cycles per second. That is 3 million cycles per ms. Now, I don't exactly know how this relates to bitrate, but that's a lot of CPU cycles per ms. This is another reason why I'm having a hard time following your logic. I'm sure CPU scheduling and processing priorities will take a toll on everthing else that requires real time efficiency, but still; how could this kind of power not handle a very data-light operation like a MIDI transmission, I can't understand. And still, the explanation that makes sense to me is lack of resolution. Jitter is part of audio streams as well - although admittedly I'm not sure that this is the case when audio data is still "within" the computer. But since audio jitter is so infinitely small in time; we hear audio jitter as a sonic effect rather than something like a tape drift - which is more like what MIDI does. So if MIDI jitter too was much more smaller in time, I'm guessing that we would lose the audible timing inaccuracies altogether.

The link that Francesca provided above pointed to a site where a builder was carrying MIDI over audio with zero latency and jitter. Here's a direct quote from that link:

I don't yet know how he encodes MIDI into audio and then decodes the same back into MIDI, but that tells me that once you increase the resolution, you get the chance to clean MIDI of audible timing artifacts altogether.

Anyways; I'm having a lot of fun with this discussion - please don't get me wrong; I'm just trying to think together here!

Let me make one final thought exercise and go out on another limb! So let's say the processor scheduler is at fault in not prefectly lining up MIDI bits in time. If my thinking is correct, (3,000,000 cycles/ms * 0.32 ms = 960,000 cycles), one MIDI tick has to take place every 960,000 cycles. So the scheduler is very busy, the MIDI process doesn't have real time priority and the scheduler messes up by one half to process the next tick at the 1,440,000th cycle. That would be a jitter of about 0.16ms. Now let's say MIDI speed was a thousandfold at 31.25 Mbits/second instead of 31.25 Kbits/second. That would force the scheduler to place a MIDI tick every 960 cycles. In this case, even if the scheduler messed up, and placed the next tick 1440 cycles later instead of 960, that timing error would not be noticeable by ear.

OK. I bet I've misinterpreted a lot of technical basics, but hey I've done my best to make sense of things…

Oh and I wish all a happy new year!

Derin.