The Truth About Latency: Part 2

Latency And Latency Jitter: Real-world Tests

Published in SOS October 2002
Bookmark and Share

Technique : PC Musician

One of the tightest software MIDI Thru functions is provided by MIDI-OX, which runs on Windows 98, ME, 2000 and XP. This is the last article in a two-part series. Read Part 1.
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?


Martin Walker

In last month's SOS 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 opposite 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

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.

  More On Real-world Audio Latency  
  Last month I explained how to measure real-world audio latency using an external synth as a signal generator, plugging this into one stereo channel of your soundcard, and then looping the monitored version via your soundcard's analogue output back into the other stereo input channel. The inter-channel timing difference is the total latency of the input and output software buffers, plus whatever constant delay is added by the A-D and D-A converters, and anything else in this signal path.

Since I was rather surprised at the high value of 189 samples measured on my Echo Mia, which effectively adds about 2ms to both input and output at 44.1kHz, I contacted Echo for clarification, and received a fascinating insight into what goes on under the bonnet of a typical soundcard. The AKM AK4528 converter chip itself adds a 31-sample latency for the ADC oversampling digital filter, and 30 samples for the DAC. At under 1ms at 44.1kHz, this is about what I was expecting.

However, for PCI buss efficiency, the soundcard DSP has tiny additional 32-sample internal buffers on each side as well, and it turns out that an additional 32 samples are used for real-time sample-rate conversion in each direction, when operating at 32kHz or under. This explains my total measured value (31+32+32+32+32+30 = 189). So now you know how some soundcards manage to support new sample rates after a driver/firmware update — it's extra DSP code that runs on the card itself.

I've since measured the onboard latency of M Audio's USB Duo at 152 extra samples, while the ESI Pro WaMi Rack 192X's is lower at 91 samples, presumably because it has no SRC and uses smaller DSP buffers. With most modern soundcards the real-world audio latency is always going to be between one and two milliseconds greater than the software buffer size both when recording (input) and when playing back soft synths in 'real time'.

By the way, if any of you want to take real-world audio latency measurements further, there are various other possible configurations. If for instance your card has S/PDIF I/O, you can use a loopback cable between its out and in to perform a similar test to my analogue one. You'll still need to somehow patch the left output to the right input to avoid howlround — I managed this using the Mia's Console utility, which has pan controls on the input monitoring — but the difference between this digital measurement and the analogue one should be just the delay caused by the ADC and DAC.

 

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 te

Even if you don't get audio clicks and pops, having the correct graphics card settings may improve MIDI timing jitter.
st 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.

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.

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 j

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.
umps 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 u

  Test Signals  
  Last month I described how to create a suitable test signal with a fast rise time, using a soft synth or external synth, to make measuring your own MIDI and audio latencies somewhat easier. However, there are also various freeware utilities available for download that are written for just this purpose. I first mentioned Paul Kellett's TestTone way back in SOS September 2000: it's a signal generator VST plug-in which has options for sine waves at all ISO 1/3-octave frequencies, sweep tones, white and pink noise, and even single-sample impulses.

The latter are ideal for our purpose, since they make it easier to exactly measure timing relative to another signal. TestTone is in Pack 4, which you can download from the Effects page at www.mda-vst.com. You can also create an impulse WAV file by hand, as described in PC Notes September 2002, and this is ideal when testing applications like software samplers or fully fledged MIDI + Audio sequencers.

One possible complication when using a soft synth instead of a hardware one as signal source is when testing host applications that automatically adjust the start time of audio recordings to take account of software buffer latency. If your sequencer automatically compensates for latency, the safest way to avoid it is to use a stand-alone soft synth. However, you can then run into problems trying to run both MIDI + Audio sequencer and soft synth simultaneously on one soundcard. One solution for those with two PCs is to use the second as a signal generator.

 
nder 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.

  Windows XP MIDI Drivers  
  Together, the Intel 2001 Guidelines and Microsoft WHQL (Windows Hardware Quality Labs) now prohibit the use of MPU401-style interfaces, as well as direct driver access to either the serial or parallel ports, which means that once again the system triumphs and both latency and jitter will suffer.

However, it seems that I was too hasty when saying last month that it's very difficult to find serial or parallel-port drivers for the larger MIDI interfaces on the Windows NT/2000/XP platform. Although many manufacturers are abandoning both serial and parallel in favour of USB with new designs, some are releasing other options where appropriate. For instance, Midiman now have a beta serial-port driver available for Midisport 8x8/s users running XP, which gave me slightly low latency and jitter results than the latest USB drivers. Ego Sys also have XP drivers for their Miditerminal 4140 four-in/four-out interface, which uses the parallel port, and they even say on their web site that it has much better MIDI timing compared to USB.

Most of MOTU's MIDI interface range is available in either serial/parallel or serial/USB versions, and they seem to have Windows 98, 2000 and XP drivers for all of them, although they do warn that older models of the USB Micro, Express XT and MTP AV may need upgrading to incorporate a Windows-compatible USB chip. Those with an M/W indicator on the bottom panel label are fine.

As an aside here, if you are using a USB MIDI or audio interface, you should always plug it into a dedicated USB port rather than via a USB hub (powered or otherwise). Hubs multiplex the combined data from several USB devices into one data stream, so they're almost bound to introduce timing uncertainties — Griffin Technology (see July 2002 News) have introduced a USB hub optimised for audio devices for just this reason. However, if like me you now have several USB dongles, these can safely be plugged into a hub, since timing isn't an issue.

In view of Emagic's takeover by Apple, it's perhaps just as well that their AMT8, Unitor8 and MT4 already have XP drivers. However, Opcode's range, such as the parallel-port eight-port SE, will never get Windows 2000/XP drivers now that Opcode development has ceased. Since Opcode also took over the MusicQuest interface range, these won't ever get them either.

For the tightest XP timing, it's also important to make sure that you have installed any relevant OS updates from Microsoft. One that specifically deals with periodic audio pops with USB speakers as well as possible data transfer errors with a USB modem is discussed in article Q307271 at Microsoft Support (http://support.microsoft.com), and you can also download an associated 1MB EXE file and run it to apply the patch. If you're not suffering from any problems, the update will also be part of the forthcoming Windows XP Service Pack 1.

 

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 PP

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.
QN (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).

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 a

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.
s 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).

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 m

  FireWire & MIDI  
  The IEEE 1394 standard, known as FireWire to Apple and iLink to Sony, is a serial protocol, and can support multiple data streams running in both directions simultaneously at speeds of up to 200Mbps. This can support up to 100 digital audio channels, along with up to 256 16-channel MIDI ports. Unlike USB, which was largely introduced to support such devices as scanners, mice and keyboards, FireWire was also designed with multimedia in mind, including both MIDI and audio. It has another huge advantage over USB in that the data is time-stamped, and multiple streams should therefore stay in perfect sync.

The only disadvantage of adding a FireWire port to a MIDI interface at the moment seems to be that the extra hardware needed costs considerably more than a serial, parallel or USB one, and for this reason there are no currently available models. Prices will hopefully soon drop to make this more feasible, but when more keyboards and synth modules have FireWire ports, you may not even need a multi-port MIDI interface — you could just hot-swap them together into one long chain connected to your computer. This of course assumes that your computer also has a suitable FireWire port, but many laptops already have one as standard, as does Creative's Audigy soundcard, and you can already buy a PCI card with three or four FireWire ports for about £35.

 
s 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.

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

Steinberg's Midex 8 is claimed to offer tighter MIDI timing with Cubase and Nuendo, thanks to the company's Linear Time Base technology.
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.

This is the last article in a two-part series. Read Part 1.
DAW Tips from SOS

 

Home | Search | News | Current Issue | Tablet Mag | Articles | Forum | Subscribe | Shop | Readers Ads

Advertise | Information | Privacy Policy | Support | Login Help

 

Email: Contact SOS

Telephone: +44 (0)1954 789888

Fax: +44 (0)1954 789895

Registered Office: Media House, Trafalgar Way, Bar Hill, Cambridge, CB23 8SQ, United Kingdom.

Sound On Sound Ltd is registered in England and Wales.

Company number: 3015516 VAT number: GB 638 5307 26

         

All contents copyright © SOS Publications Group and/or its licensors, 1985-2014. All rights reserved.
The contents of this article are subject to worldwide copyright protection and reproduction in whole or part, whether mechanical or electronic, is expressly forbidden without the prior written consent of the Publishers. Great care has been taken to ensure accuracy in the preparation of this article but neither Sound On Sound Limited nor the publishers can be held responsible for its contents. The views expressed are those of the contributors and not necessarily those of the publishers.

Web site designed & maintained by PB Associates | SOS | Relative Media