Users of Steinberg’s Nuendo and Cubase often run into trouble with MIDI timing. I’m not affiliated with Steinberg, but I am a programmer, and I’ve done a lot of experimenting with MIDI timing on the PC. Here is, I hope, the definitive list of problems and workarounds. Note that I talk mostly about Nuendo here, but Nuendo and Cubase SX are the same application under the covers, and everything I write applies to both. The explanations are lengthy, but it’s a complicated topic, where many problems can cause the same system, and I think it’s important to understand the background; if you think I should provide a long and short version of this FAQ, leave a comment to that effect.

1. Emulated PortsBy far, the most common cause of MIDI timing problems is using emulated MIDI ports. Once upon a time, there was only one type of MIDI driver, known as Windows MIDI. Later on, Microsoft introduced a new driver type, DirectMusic, which could theoretically offer better timing, but due to some limitations, this was mostly taken advantage of by gaming cards, not pro-audio cards.

To encourage application developers to switch from Windows MIDI to DirectMusic, Windows provides “emulated” DirectMusic ports for all Windows MIDI drivers; as far as the application knows, it’s talking to a genuine DirectMusic driver, with Windows doing the translation under the covers. This means that an application like Nuendo can, in theory, be written solely to the DirectMusic interface, and if your card doesn’t actually support DirectMusic, Windows will cover for it.

The reality is more complicated; sometimes the emulated DirectMusic drivers don’t work at all, or only work in one direction. Sometimes the emulated ports don’t work but the original Windows MIDI ports do. Sometimes the timing is off on one port or the other. Sometimes there are actually both Windows MIDI and genuine DirectMusic drivers for a device. So if there is both a Windows MIDI and DirectMusic version of a port, Nuendo tries to guess which one is the right one, and it filters out the other. Sometimes—usually, in my experience—it guesses wrong, especially where emulated ports are involved. And on some systems, though certainly not all, the emulated ports have timing problems.

(By the way, these two driver types—driver APIs, really—have nothing to do with WDM vs. MME drivers. Those are driver models, and affect how a driver is built, not what API it uses. A WDM driver can be either Windows MIDI or DirectMusic, and I believe the same is true of MME. We don’t care about WDM vs. MME here.)

The fix

Nuendo keeps a zero-length file called ignoreportfilter in the directory C:\Program Files\Steinberg\Nuendo\MIDI Port Enabler. Using Windows Explorer, you can drag this file up one level to the Nuendo directory, restart Nuendo, and you will now see both the emulated and non-emulated ports. In my experience, you nearly always want the non-emulated ports; you should go into Device Setup and set “Show” to “No” for the emulated DirectMusic ports so that you don’t accidentally use them.

This will only solve your problem if yours is a system where the emulated ports have timing issues. On my system, they don’t.

2. The two-clock problemAll MIDI interfaces on Windows timestamp their data before providing it to the application. This avoids timing problems when the application doesn’t immediately see the incoming notes, perhaps due to higher-priority interrupts, or things chewing up CPU time, or simply a burst of notes too quick for the app to process. The app just looks at the timestamp, does a quick calculation, and poof: instant latency compensation for all MIDI. This has been part of the MIDI driver spec forever.

But Windows provides two different multimedia timers - specifically, one called timeGetTime, or TGT, and one called QueryPerformanceCounter, or QPC. The QPC timer is more precise (although the actual precision is up to the motherboard), and often more accurate, but it’s only available on newer versions of Windows, and there were some motherboards a while back that had major inaccuracies with it, and some current dual-CPU boards still don’t keep the two CPUs in sync.

So drivers, especially Windows MIDI drivers, that descend from older code, or have to work on older OS’s, or that are simply more cautious, are likely to use TGT, which is what Nuendo normally uses; the VST and ASIO specs are based on TGT. Newer drivers, especially those written under DirectMusic, are likely to use QPC. Since the two end up out of sync on most PCs, you’ll end up with timing problems in Nuendo if your MIDI driver uses QPC.

This problem is likely to affect any sequencer, not just Nuendo - although some sequencers might be based around QPC instead of TGT, and thus they’ll have problems with exactly the interfaces that work fine on Nuendo and vice versa. Sonar does have a hidden option that lets you ignore ALL timestamping from the interface, which is fine unless Sonar can’t keep up with the interface, at which point you’ll have really sloppy timing on ANY interface.

The fix

Nuendo and Cubase 2.20 provide an option in the DirectMusic settings called “Use system timestamp”. This tells Nuendo that for MIDI tracks, they should keep track of time using QPC, not TGT. This affects only DirectMusic drivers. That means that if you have a Windows MIDI driver that uses QPC, you’ll have to use the emulated DirectMusic drivers, which is the exact opposite of what is normally recommended! Hopefully future versions will offer this option in both DirectMusic and Windows MIDI flavors. Meanwhile, hopefully your system isn’t one of those that has timing problems on the emulated ports. My system, an Asus P4C800-E, doesn’t, but certainly some do. A future version of MIDITime will test DirectMusic emulated ports as well, so you’ll know exactly what you’re up against.

The test

If you want to be certain that this is the problem you’re having, and help out the user community at the same time, you can download my MIDITime Utility. You take a cable from a MIDI output port to a MIDI input port, and run the utility until your clocks get out of sync; it then tells you which clock is correct, and thus what setting to use. Simple and definitive.

And please, if you run the utility, and your interface isn’t already listed below, e-mail me the results so I can share them! (I’d prefer that you not leave them as comments, so others don’t have to wade through the details.) The utility can take up to an hour to run (it waits that long to decide that your clocks are staying in sync), but more often takes about 5 minutes.

If there are any Windows programmers out there interested in slapping a simple GUI on this app, drop me a line. I never bothered to learn MFC, and with Windows.Forms and .NET coming of age, it’s not really worth it now.

The results

The following MIDI interfaces will work best with the DirectMusic emulated ports and the “Use System Timestamp” option checked:

Wami Rack-24The following MIDI interfaces will work best with the “Use System Timestamp” option unchecked:

Aardvark Q10Edirol UMT-880Emagic Unitor8 MK1Emagic Unitor8 MK2Emagic AMT-8M-Audio MIDISportRME DigifaceRME 9632The following lucky motherboards have clocks that don’t drift, and so can use any interface with any setting:

Asus A7V333Asus A7N8X-XAsus P4D-800DAsus P4T-533CAsus TUSL2-C3. Constrain Latency CompensationOne person has reported that using the Constrain Latency Compensation option—which should, in theory, affect only audio—also improved his MIDI timing. This has not been confirmed by other reports, but it’s certainly easy enough to try. If you find this setting to be helpful, please let me know.

Posted by: driskel at May 15, 2004 08:58 PMThe first time I ran the utility, it took a minute or so.

Every subsequent time it finished in 0 seconds.

Each result was saying check the 'use system time' box. But I only trusted the first set of results.

ASUS A7V266-EMIDEX 8

barnaby.

Posted by: Barnaby at May 17, 2004 01:53 PMI tried to run MIDItime on my system. It says something like 'No midi output on system. Please specify ports used'.I run a dual Xeon on Intel mother board, Windows Server 2003, and use a MIDEX3. Nuendo finds it and loops perfectly (apart from a sample or two delay).I would like to check with your utility - what am I doing wrong?

RegardsWillem

Posted by: Willem at May 18, 2004 04:09 AMThe MIDEX3 has a DirectMusic driver, but not a Windows MIDI driver. MIDITime currently works only with Windows MIDI; I should have a new version this week that checks DirectMusic as well.

Results:need to set the 'Use the System Timestamp' option. Must use the emulated port.

Thank you very much for your utility.

Posted by: Raibearth at May 18, 2004 06:07 PMJay -- how incredibly valuable... I can't thank you enough for your work. I haven't been able to play with the 2.2 update much, but I have high hopes now - maybe I won't have to quantize each and every single &*(#$ track

If you get bored, I would certainly be interested in the meaning behind some of the variables you are tracking in the .log file.

Posted by: Cliff at May 19, 2004 10:43 PMSure thing! The round trip times are exactly what they sound like - how many milliseconds it took for each note to be received, by subtracting the timestamp provided by the MIDI driver from the current time according to both the TGT and QPC clocks. If either clock goes out of bounds (see below) a bunch of times, it decides that that clock must be inaccurate with respect to your MIDI driver.

The "start" and "sent" times are the time of the start of the run and the time the last note was sent, according to each clock. They are used to calculate the round-trip times, since the "timestamp" from the MIDI driver is actually relative to the start of the run.

The "in bounds" flags will be false if the round-trip time is negative, or if the round-trip time is greater than 40ms on this clock (but not the other) and if that's happened five times.

The "delta" is just the round-trip time of the last run, and "avg" is the average time across the whole run.

"Slow responses" is how many responses we received that were greater than 40ms.

"QPC frequency" is the reported clock frequency of the QPC clock according to the PC; we use that to translate QPC "ticks" into milliseconds. (The PC can use any unit it wants for the QPC clock; some use your CPU clock, others use other clocks available on the motherboard.)

"Run" is the length of the run in seconds, and "Drift" is the difference between the two clocks in *micro*seconds, although the TGT clock is only precise to a millisecond, so don't read too much into the last three digits...

"Device", "Driver" (version) and "CPU speed" are as reported by the PC.

Posted by: Jay Levitt at May 24, 2004 06:24 PMThanks you really uncovered it for me. I suspected that there was time stamp issues with the drivers. It would be nice to find out what motherboards out there have good stable clocks.

Posted by: PugFace at June 4, 2004 09:33 AMHi Jay:Thank for the help, I'm losing my patience with big bad Nuendo.2.2 I ran the midi check and it told me to configure my devices as they were already set up, I also tried your other two trouble shoots.Still I have midi timimg probs, after time working, the only way to fix it is to close the app and reopen,btw i use a midisport 4x4 with windows XP

Your solutions here have really helped with a basic starting/setup problem I was having.I have always used the USB Midisport Uno 1x1 as the interface between the Karma and Cubase VST and have had no problems. But under CubaseSX2.2 the UNO is an emulated port.The problem went like this:-new project-add midi track-play a patch on the Korg Karma-then change the patch by the dial on the Karma and then the entire midi system in CubaseSX would lock up!!The whole system was snarled up completely. I couldn't shut down Cubase - program not responding etc. The only solution I found (between tearing out my hair) was to use the Audiophile Midi interface (which, by the way, wasn't emulated) and to filter out program change messages in Preferences in Cubase.However, by making visible the non-emulated ports as per this very informative page, and using the non-emulated ports, the system and everything is working as normal.Thank-you very very muchI hope my somewhat lengthy description is useful to someone.Again thanksVolker

Posted by: Volker at July 19, 2004 12:17 AMThank you very much for all your research!I would like to know if this problem is seen only on specific motherboards? or does everyone suffer from this?

Thanks,Yaron

Posted by: Yaron at July 22, 2004 07:33 AMI used miditest.exe by Eerth Vega ConnectionIt gave me sub 1ms results using windows midi and 6 to 20 ms results using direct midi depending on the complexity of data. The thing with Nuendo 2.2, I get around 6ms average timing at low buffer settings (1.5ms on the RME control panel) but worse up to 20 ms av timing with higher buffers. Catch 22 is that I can't have many plug-ins at 1.5 ms buffer so the midi sounds ok but can't do much in the way of audio tracks.I use windows midi not direct midi with the timestamp option off. I wish Nuendo would give me sub 1ms midi timing that I know my RME is capable of.My setup..Laptop by Clevo 5700p.P4 1.8 with 750Meg Ram.RME cardbus Hammerfall DSP with Digiface.I'm currently running the miditime.exe from this page, zzzzz, I'll post again with the findings.Posted by: Pac at July 27, 2004 01:24 AMThe results are in. "Amazing! After an hour, both you clocks stayed in sync.." blah blah, good for me.But I still have questionable midi timing - not rock solid. (see my post above)some info from the log..TGT delta: 1 QPC delta: 6TGT avg: 1.667 QPC avg: 6.318I wish Nuendo behaved like it was on TGT like your article sugests. ANY IDEAS WELCOME. groove_state@hotmail dot comMotherboard has an Intel(R) 82801 - PCI Bridge, SMBus, LPC.Intel(R) 82845 Processor to AGP Controller, Processor to I/O ControllerHope this helps.

Posted by: Pac at July 27, 2004 03:21 AMMy set up:

MOTU 1820Asus P4P800-ECubase SL 2.0Roland v-drums & Yamaha Motif ES8

The problem: a delay (latency) between the midi instrument and the signal in Cubase.

Attempted fixes and results:1. Emulated Ports: moved file, did nothing. All ports are (Emulated) before and after the file move. 2. Two clock problem: ran the utility... it ran for 18 hours before I called it quits. What does this mean, Jay???3. Constraint Latency Compensation: no difference.4. Issue still not resolved! The folks at MOTU are stumped; I will be calling Steinberg next to see what they say. Thanks for supporting the community Jay!

Posted by: Kelly at July 28, 2004 10:41 PMI have an ASUS motherboards (actually two) and have little miditiming issues, still this document and the clear explenation of the subject has clarified more.As a Cubase SX 2.2 user i did not find this information on their website or forum, while i was looking for it a long time.Would it be a hassle for Steinberg to program their apps to the better timing state, like its clear to me the workaround can be programming in the application....Thx , its been a good deal out hereKeep up the good work

Posted by: Marcel at July 29, 2004 02:48 PMHi all. I'm using Cubase se on a p4 2.1 ghz 768mb ram, M-Audio audiophile usb interface. My problem is only one thing. Everything works perfect except when I try to record midi. It plays thru fine while the sequencer is in play mode, but as soon as I press record, the sound cuts out. If I press the record button on the transport without enabling record on the track it plays but doesn't record anything. If I enable the track, play then record, the sound stops, but when I press record again while still in play mode, the sound starts playing. i really need help. I tried everthing I could find similar to my problem on the net, but still the same problem. HELP...

Posted by: Trev Gee at August 3, 2004 08:47 PMHi all. I'm using Cubase se on a p4 2.1 ghz 768mb ram, M-Audio audiophile usb interface. My problem is only one thing. Everything works perfect except when I try to record midi. It plays thru fine while the sequencer is in play mode, but as soon as I press record, the sound cuts out. If I press the record button on the transport without enabling record on the track it plays but doesn't record anything. If I enable the track, play then record, the sound stops, but when I press record again while still in play mode, the sound starts playing. i really need help. I tried everthing I could find similar to my problem on the net, but still the same problem. HELP...

Posted by: Trev Gee at August 3, 2004 08:47 PMwell, i use Nuendo 2.2.0.35 beta, and Cubase 1.06, in both Programs happen the same thing, when I work in Midi don't have any problem, The timestamp is incorrect when i made a record from any midi outgear, like my EMU Proteus 2500 or Clavia Nord Lead SX2, I work in a Pentium 4 3.4 Ghz 1024 Mb Ram, on Intel motherboard D875PBZ, and I use a MOTU 8288mkII firewire, and I use the MIDI port of the MOTU interface

Posted by: Carlos Alberto Rios at August 4, 2004 01:25 AMI have done the test with toshiba satellite notebook, p4 2.8 1gb ram, and rme hammerfall multiface. I got 0.9 ms latency. I got a message to seactivate the time stamp. But I am working with cubase sx 2 and I didn't find any such setting in cubase sx 2. Is there a way to deactivate it?

I really appreciate what you are trying to do. This page has given me some insights.

However, I feel that there are a couple of points where your information is not correct or incomplete.

To start off: DirectMusic drivers are the only MIDI drivers that timestamp MIDI data. Older drivers could not do this. It's quite a crucial difference. How and where MIDI data is timestamped depends on API used (MME or DirectMusic) and the type of driver. If you use the MME API then MIDI data is timestamped by the MME OS layer, not by the driver. If you use the DirectMusic API then the timestamp is either derived from the driver (if it's a true DirectMusic driver) or done by the OS layer (for emulated ports).What this means is that the device driver has absolutely no influence on which clock is used to timestamp. The DirectMusic API uses a timestamp based on units of 100 nanoseconds. I am pretty sure that this clock is derived from QueryPerformanceCounter in all cases (but only Microsoft could tell you that for sure).The MME API uses a timestamp based on units of 1 millisecond. Whether this timestamp is based on QueryPerformanceCounter I could not tell you. What I do know is that the MIDI driver has no influence on this. It's an OS matter.

The effect this information has on the decision which MIDI port to use is hard to say. The big problem is that we can only make educated guesses about what exactly goes on inside Cubase SX. Steinberg is reluctant to provide information, to say the least.

My own feeling is that in most cases it's best to use the DirectMusic ports because they have a much more precise timestamp. If there are no true DirectMusic ports, use the emulated ones.

One good reason to use the windows MIDI ports is if you want to be able to record sysex dumps. This simply does not work with most DirectMusic drivers (and that IS a driver issue).

It surprises me to read that the Midex8 works best in emulated mode. As far as I know it is not even possible to use it in this mode with Cubase SX. This at least is true for the Midex3 and I'm guessing that the same is true for the Midex8.

I am still investigating the option of 'Use system timestamp'. It is still unclear what Steinberg means by that. My own tests indicated a substantial increase in MIDI timing jitter when this option was CHECKED. This was the case with true DirectMusic ports. Emulated ports didn't seemed to suffer from this effect. I somehow suspect that by checking this option you tell Cubase NOT to use the DirectMusic timestamps, which is the exact opposite of what I thought it would do.

All wav audio record/playback synchronisation is obviously fine but midi plays back roughly a quarter bar before the passage was actually recorded. It drops the first note/s played (which Cubase effectively perceives as being played before the timing bar even reaches the left marker). Very strange. I am surprised that this is happening with this equipment. Any ideas? I'll download your utility and try that, but surely this is a simple configuration fix? It's been driving me mad. I also have a Soundblaster Platinum installed that I use for some sound fonts etc. It's stereo output is routed back into a pair of the Delta inputs as I have an external mixer (Tascam m1600) but it is not available at the moment as life's a bit nasty ...it's round what is fast becoming my x's house! I will in time hopefully get this back and integrate it into the setup to free up some delta inputs. PS I nearly purchased...dare I say it a 16 Track analogue reel to reel the other day!!, but these sync errors for the moment deterred me! At the x's I also have a Tascam 58 + Dbx X 8 which was a lovely recorder but two of the channels have meter send failures after I tried to hard wire everything a couple of years ago which became annoying. Also an ATARI 1042 4MB + black/white monitor and oceanic 20MB external hard drive....fabulous!!! Rock solid midi. nuff said.