In the second part of our investigation into the real-world delays caused by PC hardware and software, we consider the differences between different MIDI applications and versions of Windows. Are some sequencers really 'tighter' than others?
In Part 1 last month, I reported my initial enquiries into the difference between the latency reported inside software sequencer and soft-synth applications, and the measured real-world latency, including all the other delays due to such things as analogue-to-digital and digital-to-analogue converters. Sometimes these include unreported buffers that are situated on the soundcard itself, and there are a few rogue soundcards whose actual latency is considerably different from that displayed by software. Most, however, play the game and add only a small amount of 'extras' (see box for my further findings).
I also spent a considerable amount of time investigating the other and often forgotten aspect of 'real-time' soft-synth performances — the latency between pressing a MIDI key and the MIDI note on message reaching the software. Unlike hardware synths, where typical values are between 3ms and 5ms but stay almost exactly the same each time you press a key, MIDI data passing through a PC MIDI interface faces the added uncertainties of the Windows operating system, and while a similarly low latency may be possible, the latency jitter (variation each time you press a key) may be considerably higher.
A Brief Recap
One of the tightest software MIDI Thru functions is provided by MIDI-OX, which runs on Windows 98, ME, 2000 and XP.In general, my findings seemed to suggest that the lowest MIDI latency is provided by PCI card interfaces (or those on PCI soundcards), followed closely by serial/parallel port devices, and finally USB interfaces, whose data seems to face the most uncertain path. Moreover, sometimes using a USB audio interface may affect MIDI to soft=synth latency, as I discovered when triggering a soft synth running on M Audio's USB Duo. Despite its excellent USB audio performance, it had the highest MIDI latency figure I measured: M Audio have since confirmed my findings and their driver experts are looking into the cause of the problem. There's no point me giving cast-iron values, since these will vary from interface to interface and perhaps even between driver versions. However, in every case there was significant latency jitter. The best figures were provided by Tascam's GigaStudio 160 which, when used with my test PCI, serial and USB MIDI interfaces, despite each giving slightly different overall latencies, always measured almost the same low 3ms of jitter.
Most other software displays higher jitter figures, depending on how the MIDI input data is handled. NI's Pro 52 prepares multiple 5ms buffers for MME playback — which is why its Play Ahead setting increments in 5ms jumps — and I measured its jitter at 5ms. Similarly, ASIO drivers exhibit MIDI latency jitter that depends on their buffer size. To get similar jitter levels to GigaStudio you need to use 128-sample ASIO buffers, but this means a low overall latency of just 2.9ms, and many musicians will find this too small a value to avoid audio glitching unless they are using a very fast and well set up PC.
With a more practical 256-sample ASIO buffer (5.8ms at 44.1kHz) I measured around 5ms jitter, while for a 512-sample buffer (11.6ms at 44.1kHz) this jumped to about 12ms, in line with my explanation in SOS November 2000. This is a design decision, since reducing latency jitter comes at the expense of increasing overall latency.
|
Some Issues Resolved
These jitter values can be directly attributed to driver design, but some of my other measurements exhibited occasional values that were much higher, suggesting interference from other sources such as Windows activities. For instance, my first batch of PC measurements were made using different types of MIDI interface fed through Gary Gregson's XGedit utility into my SW1000XG hardware soundcard synth. This test was intended to measure the simplest possible MIDI path that enters the PC and uses software drivers — hardware MIDI input, via software drivers, software Thru, to internal MIDI hardware synth. However, whether I used a PCI, serial-port or USB interface, I got occasional readings that were significantly higher than the remainder.
Even if you don't get audio clicks and pops, having the correct graphics card settings may improve MIDI timing jitter.The reason for this turned out to be that XGedit's software Thru is only really intended for auditioning sound edits, and not as a real-time performance tool. Since it uses a simple user mode routine, its timing can be compromised under Windows 9x/ME by the 'thunking' layer between the 16-bit multimedia code and the 32-bit user mode, and particularly by graphic updates and other background OS functions. Further investigation showed that for my timing test purposes it might be better replaced by a utility purpose-written for real-time performance — my old favourite MIDI-OX (www.midiox.com).
This provides a tick option to automatically connect inputs to outputs when you select them and, sure enough, gave me very much tighter readings. For the SW1000XG PCI MIDI input, instead of the 3.4ms to 3.9ms readings with occasional jumps as high as 11ms I measured running on Windows 98SE last month, I measured values from 3.5ms to 3.6ms — a vast improvement, illustrating just how much your choice of software can affect MIDI timing. I found a similar improvement using the same setup with my Midisport 8x8/s using serial drivers: last month's 4.2ms to 4.9ms, with occasional jumps to 7.7ms, gave way to a very much tighter 4.0ms to 4.5ms. The PCI interface still shows a slightly lower latency and jitter than the serial-port one, but both are now far closer to hardware MIDI timings than before.
As long as you make sure you avoid any 'emulated' MIDI driver entries, Cubase SX provides excellent software Thru performance under Windows XP, with minimal additional latency and jitter.After uninstalling the Midisport's serial drivers and replacing them with USB ones, I once again experienced improved performance compared to last month's figures: the 7.0ms to 9.1ms with occasional jumps as high as 13ms now measured 7.0ms to 8.9ms with no jumps. This jitter of about 2ms won't normally be audible.
Windows XP MIDI Timing
Now that timings were more solid, it seemed a suitable point to introduce Windows XP into the proceedings, especially as this promises to be the future for the PC musician. Many musicians had serious MIDI timing problems with Windows NT, and some music developers never directly supported it for this reason. Many also had similar problems with the subsequent Windows 2000 when they left Windows 95/98 applications on their hard drives during the Windows 2000 install and then carried on running them afterwards.
On single-CPU systems, Windows 2000 can cause audio and MIDI timing problems if you leave it on the default ACPI Mode, due to the way it implements IRQ sharing. The best cure for this is to change to Standard Mode, as I described in my Windows XP Tweaks feature in SOS March 2002. However, in general, Windows XP's ACPI and interrupt handling seems to be more stable and reliable, although plenty of musicians are still switching to Standard Mode to get rid of glitching problems with certain soundcards.
Using MIDI-OX once again, I repeated my software Thru test as above, and found that the figures for my SW1000XG PCI MIDI input now varied from 3.6ms to 3.8ms — almost exactly the same as under Windows 98SE, although with a slightly smaller spread. My MIDIsport 8x8 now has beta serial-port XP drivers, and these measured 4.2ms to 5.4ms — again very close to the equivalent Windows 98SE figures, but with a slightly larger spread. I think we can assume from this that to all intents and purposes, Windows 98SE and XP provide almost identical MIDI timing performance with well-written drivers and a correctly set up PC.
|
However, after uninstalling the XP serial-port drivers for my MIDIsport 8x8, and replacing them with the latest USB versions, I measured 4.8ms to 6.0ms, with an occasional jump (one in seven or eight readings) as high as 11.2ms. Since the other software-related jumps had disappeared, I had a hunch that this was more likely to be buss-related. The PCI buss is used by quite a few components of the PC, including the 32-bit wide expansion slots, AGP slot, the hard disk controller, and the USB Host controllers, and this gave me a clue as to a possible cause.
Windows XP had identified my Matrox G450 graphics card correctly during setup, and installed a default set of drivers for it. However, these had none of the extra menu options normally provided by the Matrox PowerDesk software, and specifically, no tick box to disable its buss mastering. I therefore used the Matrox uninstall utility to completely remove all references to the G450, rebooted, and then installed the latest XP drivers. After unticking the 'Use buss mastering' tick box I once again rebooted, and repeated my software MIDI Thru measurements.
This time, values were between 4.8ms and 6.7ms every time, with no jumps. This proves how important it is to set up your graphics card for music purposes, even if you don't hear clicks and pops from your audio. Moreover, although XP's jitter performance was almost identical to Windows 98SE's, the latency itself was significantly better than the latter's 7.0 to 8.9ms. Of course these results are only from one MIDI interface, but it does tend to tie in with reports I've read of USB performance sometimes being better under XP.
Of course there are other operating system settings that may affect MIDI timing for similar reasons. Make sure your hard drives and CD-ROM drives are both using Buss Master DMA if possible. You're highly unlikely to access a CD-ROM drive while running your MIDI + Audio sequencer, but your hard drive will almost certainly be used, and both devices will otherwise consume a significant proportion of your CPU overhead. Unlike some rogue graphics cards, they don't tend to have nasty habits, and won't hold onto the buss while receiving requests from other devices to access it in turn.
Also, make sure your swap files (or page files in Windows 2000 and XP) have a fixed size, by setting the minimum and maximum virtual memory settings to the same value. This will ensure that they don't attempt to adjust themselves while you're transmitting or receiving MIDI data. If you have 512MB or more of RAM, you should be able to safely disable virtual memory altogether.
|
Sequencer Software Thru Performance
Given this tighter performance, it seemed sensible to try the same test using a typical MIDI + Audio sequencer, to see whether a more complex application manages similar timing figures when used to provide software Thru functions. Cubase is my application of choice, so this is what I tried first. Settings such as PPQN (pulses per quarter note) only affect MIDI playback resolution, while MIDI inputs will usually be read at the highest available resolution (normally determined by Windows itself).
Sonar 2.0 also proves that complex MIDI + Audio sequencer applications don't need to compromise MIDI software Thru performance unduly, even when running under Windows 98SE.Incidentally, this is why Steinberg recommend disabling all unused MIDI inputs in MIDI System Setup, and why you should do the same where possible in any MIDI application. Just as only enabling the soundcard audio inputs you're actually using can streamline performance, by not wasting time polling the others, you can also reclaim a little CPU time and resources by disabling any unused MIDI inputs in your MIDI + Audio sequencer. After all, there's no point in having your sequencer race off a thousand times a second to check for MIDI data at a port that's not connected to a keyboard or controller, since this simply wastes system resources.
Running Cubase VST 5.1 under Windows 98SE, I measured a spread from 4.6 to 6.6ms with my SW1000XG PCI interface, and assumed that the 1-2ms increase over MIDI-OX was due to compromises when dealing with both MIDI and audio in the same application. However, on moving to Sonar 2.0 I received a pleasant surprise, measuring a spread from 3.5 to 5.0ms under Windows 98SE. The lowest figure here is exactly the same as the MIDI-OX value, while the highest is only 1.6ms more. I wasn't running at a high latency, either — I'd set up three buffers of 5.0ms in Sonar's Audio Options, giving an effective latency at 44.1kHz/stereo of 10ms. Checking this with my real-world audio latency test, I measured a total path of 1071 samples, or 24.3ms, but after subtracting the 189 'extra' samples already measured on my Echo Mia (see box), the remainder was 882 samples, or exactly 10ms on the input side plus 10ms on the output side at 44.1kHz. From this I think you can trust Cakewalk's quoted latency values.
Moving on to Windows XP, I was initially disappointed by the result with Cubase SX 1.02, which jumped to a huge 8.0ms to 8.9ms. After some investigation, this turned out to be due to the confusing emulated MIDI ports created by DirectMusic, which are redundant versions of the same physical port. The Cubase SX 1.02 update incorporates a filter to remove these extra entries, but with some MIDI interfaces it filters out the real ports and leaves the emulated ones, and this is what had happened with both my SW1000XG and Midisport 8x8. In their 'MIDI port filter.txt' file, Steinberg detail a simple fix which restores all versions of ports so you can enable the correct ones by hand, and after doing this the figures dropped to an excellent 3.7 to 3.8ms — almost the same as MIDI-OX — and I suspect that Sonar 2.0 will manage a similar performance under Windows XP.
Windows XP And Soft Synths
Once you add a soft synth into the signal chain, you have the additional latency and jitter of the soundcard's audio drivers to consider. I performed the same ASIO tests as last month, using Pro 52 in both stand-alone mode and this time running inside the Cubase SX 1.02 host application, and once again the spread of results was identical in each case. With a 128-sample buffer, and running at 44.1kHz, I measured 6.7ms to 9.4ms with the SW1000 PCI MIDI input (remember that the 3ms reported by a software application only refers to the audio buffers).
With its default GSIF driver settings, GigaStudio offers latency and jitter performance comparable to ASIO drivers running with 128-sample buffers and a 3ms latency, if your PC can manage this setting.You may remember that I was impressed last month with the performance of GigaStudio, whose three 128-sample buffers keep jitter low. With the SW1000XG MIDI input, I measured 9.8ms to 12.9ms running under Windows 98SE, and this time I measured 9.8ms to 13.0ms running under Windows XP — a remarkably consistent performance that showed the same low jitter of 3ms. However, under XP, my Echo Mia version 6.04 drivers offer a range of GSIF buffer sizes, so I was able to take advantage of an even lower 64-sample buffer size. Once again, I was able to manage the full 160-note polyphony, but this time with even better overall performance of 7.1ms to 9.0ms.
Latency Perception
Following my further tests running under Windows XP, and using various MIDI + Audio sequencer applications, last month's initial findings seem to be confirmed — PCI-based MIDI interfaces exhibit the lowest latency and jitter figures, followed by serial/parallel-port devices, followed by USB. However, before a host of USB MIDI interface manufacturers start waiting for me down a dark alley, let's place these findings into a real-world perspective — after all, this is why I started making these measurements in the first place!
My PCI MIDI interface and serial-port interface both offered latencies of the same order as a hardware synth (3 to 5 ms), while my particular USB one fared better under Windows XP, where its 5 to 7 ms latency would again be unnoticeable in the real world. Even the 7 to 9 ms I measured under Windows 98SE is unlikely to be noticeable to many people because, despite the higher figures, it still exhibits a low 2mS jitter.
Playing hardware MIDI synths using the software Thru functions of a MIDI + Audio sequencer will generally only add a millisecond of two of extra latency, but the amount does seem to vary a little from application to application. In my tests Sonar and Cubase SX performed best, but even the slightly higher figures I measured for Cubase VST 5 exhibit very low jitter levels of just two milliseconds, and are therefore highly unlikely to be noticed by most musicians.
Even when playing soft synths in 'real time', I've never personally had any real problems with a claimed 20mS latency. If you concentrate hard, you may be aware of the lag between hitting a key and hearing the note, but many piano players will already be used to this, since there is always some delay between hitting a key on an acoustic piano and the hammer hitting the string. Moreover, when you play back sounds through a loudspeaker, the speed of sound is such that each foot it travels takes about 1ms — so a latency of 6ms is equivalent to listening to a loudspeaker six feet away, which doesn't seem to bother the majority of guitarists. For a more extreme example, remember the church organ player who may be 50 feet or more away from some of his pipes!
Most keyboard players also seem quite happy with MIDI's serial protocol, which means that a six-note chord will emerge over six milliseconds, which is equivalent to each note emerging from a loudspeaker a foot further away. Only when triggering percussive sounds like drums and percussion does a latency higher than 10ms really become an issue, and in many cases such sounds are far more likely to be quantised in some way during playback anyway.
Latency jitter is far more troublesome, since the delay varies, and many musicians can detect this timing uncertainty when it exceeds about 5ms. However, many of the variations I measured both this month and last month will still go unnoticed by all but the most 'golden-eared'. Only when running soft synths with buffer sizes greater than about 256 samples (reported as 6ms inside most audio applications) will you exceed this amount of jitter, so if your PC can only manage a 512-sample buffer or larger, you may start to notice a little timing uncertainty.
|
Playback Timing
During all my tests I've concentrated on the real-time performance, because as long as you can capture this as faithfully as possible with your MIDI sequencer, there are lots of software tools available to tweak its timing afterwards if you wish. There are also various technologies available to improve playback timing at a hardware level, such as Emagic's AMT (Active MIDI Transmission) for the Logic range, Steinberg's LTB (Linear Time Base) for Cubase and Nuendo, and MOTU's MTS (MIDI Time Stamping) for Digital Performer, all of which rely on knowing in advance when a note needs to be played, and thus being able to have it ready to send on time.
Steinberg's Midex 8 is claimed to offer tighter MIDI timing with Cubase and Nuendo, thanks to the company's Linear Time Base technology.However, even with this extra help, there are still several situations where the basic MIDI timing resolution isn't sufficient. When you have several 'simultaneous' sounds, it may become increasingly important to keep them locked exactly in sync. For instance, while pad sounds may be happy even when skewed by 10ms or more from other instruments, multitracked drums will exhibit flamming when spread by even a couple of milliseconds, and in extreme cases with layered sounds you may experience notch filtering, or even phase cancellation. For this reason, it's unwise to create composite drum sounds using multiple hardware MIDI synths, as they can't be locked together to an accuracy of less than a few milliseconds.
This doesn't apply to multiple sounds selected within a single synth or sampler, since these can all be fed from the same incoming MIDI note data, so that the timing between them is a matter of internal rather than MIDI precision. However, even here you may not get a sample-accurate lock, which is one reason why so many musicians are moving over to VST and DX Instruments for drum sounds, since here you are guaranteed sample-accurate timing and can therefore indulge in layering to your heart's content. Another approach is to replace MIDI-triggered drum sounds by sampled drum loops, even if you create your own using MIDI synths, since this also ensures that your rhythms remain locked in perfect sync. Just as with audio tracks, if even a single sample in the stream slips out of place, you'll hear it as a click or pop. So, if you don't hear one of these, your soft synths are almost guaranteed to be playing back with 'perfect' timing.
Final Thoughts
When I set out to measure real-world latency figures, I did it largely to show that the soundcard's buffer size is only part of the equation. Many musicians don't realise that PC MIDI ports also add latency, but as I've shown, if you run your soundcard at buffer sizes of 128 samples or less, the MIDI component can be as large as the audio one if you're playing a soft synth in 'real time'.
Moreover, as my software MIDI Thru tests seem to prove, there's a little timing jitter added by the MIDI component, although this is always at least two or three times lower than that generated by most soundcard buffers when playing soft synths. Playing your hardware MIDI synths via the software Thru of a MIDI + Audio sequencer application may also add a few milliseconds of extra latency compared with a direct MIDI lead, but rarely any jitter, which is far more important. The huge convenience of having a visual display of MIDI data, and being able to switch from one synth to another with the click of a mouse, far outweighs these relatively small timing issues, which for the vast majority of musicians will be unnoticeable.
However, as you've seen, my 'modified MIDI lead' latency tests are an ideal way to ferret out problems with MIDI interface drivers, software Thrus, soundcard drivers, and even incorrect parameters in a PC setup. When you suspect that you MIDI timing isn't all it should be, being able to measure real-world timing can bypass an awful lot of wondering, and there's no reason why more manufacturers shouldn't be able to post typical figures using a similar setup. I've already spoken to several tech support staff who intend to make up a lead for their own purposes, and I'll continue to pursue this line of enquiries on an ongoing basis.