USB Vs Firewire PC Drives

This graph shows sustained transfer rates for read (playback) performance, as measured by DskBench for a variety of popular desktop and laptop drives.

This month we not only compare the hard-drive speed performance of USB and Firewire, but also take a look at a MIDI latency-testing utility and see how a handful of MIDI interfaces measure up.

For some time now I've been noticing PC musicians discussing the performance of external hard drives with USB connections and those with Firewire connections, wondering which interface is the faster, and how best to connect a drive if existing peripherals are also attached. This month I got hold of a dual-format (USB/Firewire) external hard drive, so I managed to do some tests for myself.

USB 2 Versus Firewire

The Iomega external drive in question contained a Hitachi (IBM) Deskstar 180GXP-120 ATA/100 7200rpm drive with an 8MB cache, 8.5ms average seek time, and a standard 40-way PATA (Parallel Advanced Technology Attachment) connector. As always, I used Jose Catena's DskBench to measure sustained transfer rates for both read and write performance, as well as the likely number of simultaneous 16-bit/44.1kHz audio tracks possible with various sizes of disk buffer (as set from within your audio application).

I connected the drive first via USB 2 and measured sustained transfer rates for read and write at 30MB/second and 25.4MB/second respectively. Track count was a theoretical 122 and 136 tracks respectively for 128k and 64k disk buffer sizes (larger buffer sizes normally give the higher result, but the reverse can sometimes apply, depending on drive buffer size and the size of the test file).

For optimum performance, it's always best to make sure you connect USB 2 peripherals directly to a port, rather than chaining them, but in the case of Firewire the situation isn't so clear, so I first tried measuring via a direct Firewire connection to the PC, and then via an intermediate M Audio Firewire 410 audio interface. I'm pleased to report that both sets of results were exactly the same, so in the case of the 410, at least, there's no performance compromise involved in connecting Firewire drives at the end of a chain (although M Audio do mention on their web site that you may be unable to boot from a drive using this connection).

The Firewire results were 30.3MB/second for read, almost identical to the USB 2 value, and the likely track counts were 121 and 135 — once again, almost identical to the USB 2 values for the same drive. However, the write performance was rather slower, at 20.3MB/second.

I'm not sure why the sustained Firewire write result is so much slower than the USB 2 one in the DskBench test, but in many cases it will be academic, unless you're attempting to record a huge number of tracks simultaneously. For most musicians, whose drives are working far harder at playback, I think we can safely say that it really doesn't matter whether you choose USB 2 or Firewire, and that you'll get plenty of simultaneous tracks either way.

Unfortunately, it didn't prove possible to extract the IDE drive from its housing to test it as a standard internal drive in my PC, using a direct PATA connection. However, according to the Hitachi specifications the drive has a sustained transfer rate that ranges from 56MB/second (presumably on the outside) to 29MB/second (on the inside). This suggests that the interface in the external drive case between the IDE drive and the FireWire/USB 2 connectors has a significant performance impact on the drive in this particular instance, although I wouldn't like to draw too many conclusions on the basis of testing just one drive.

Performance Overview

More important to most PC musicians are comparisons between the overall performance of a variety of drives. The fastest 3.5-inch desktop IDE drives I've tested to date are both from Seagate's Barracuda 7200.7 series, with a 7200rpm spin speed and a SATA/150 (Serial ATA) interface. They yielded an excellent 56MB/second sustained transfer rate for reading, while drives such as the Seagate Barracuda IV and V series (old favourites with musicians), which have the same 7200rpm spin speed and an ATA/100 interface, read at roughly 40MB/second.

Turning to 2.5-inch laptop drives I've come across, Hitachi's TravelStar 7200rpm model, from a Nusystems' laptop I'm currently looking at, isn't that far behind the drives mentioned above, at 36MB/second. The 5400rpm Seagate Momentus ATA/100 drive in my Millennium Centrino laptop is nipping at its heels, reading at 33MB/second, and the 5400rpm Toshiba MK4019GAX originally supplied with Millennium's Clevo laptop comes in with a reasonably good 25MB/second. The Fujitsu MHT2060AT 4200rpm ATA/100 model in SME Solution's Maxdata laptop brings up the rear at 23MB/second.

Personally I'm quite happy to carry on using my Seagate Barracuda IV drive for desktop audio, since it supports more simultaneous audio tracks than I'm ever going to need, and it looks as if anyone buying a laptop with a TravelStar 7200rpm drive can expect similar performance to the Barracuda IV. However, the performance of the new Seagate Momentus 5400rpm drives proves that you don't have to 'go 7200' to get good laptop performance — though it's certainly worth avoiding older 5400rpm models, and particularly 4200rpm drives, if you want to achieve maximum audio tracks.

At 30MB/second, the performance of the Iomega external Firewire/USB 2.0 drive that started me on this examination of relative drive performance is significantly better than that of many lacklustre 4200rpm and even 5400rpm internal laptop drives. Thus it's a worthwhile investment for any musician who can't upgrade an existing laptop drive, or is running out of space. However, on the basis of these one-off measurements, buying a laptop with the best internal drive you can afford is a better bet .

Testing Times For MIDI

For an article I wrote in SOS September and October 2002 ('The Truth About Latency'), I carried out a survey of real-world latency of both audio and MIDI devices. Apparently, many musicians who read the article hadn't previously realised that, in addition to the audio latency of soundcard buffers, A-D and D-A converters each add their own contribution (typically 1ms) to overall system latency. There may be further DSP processing on the soundcard (such as sample-rate conversion) that adds a few more milliseconds.

However, it's actually the MIDI path that is most prone to delays. Indeed, the timing of MIDI messages may vary considerably from note to note. This is due to uncertainties in their path (mainly caused by interruptions from other computer tasks, or data bottlenecks, particularly when audio and MIDI data is sent down the same cables) from keyboard to PC or PC to external synth.

To measure the incoming MIDI path — arguably the most important, since it captures 'real time' performances — I used a modified MIDI cable with the MIDI messages extracted as an audio signal. I could then directly compare their arrival time in a sequencer with that of the audio signal generated from the same MIDI messages by the synth (software or hardware), thus measuring 'real world' latency. This generated a lot of useful data for both the delay time (latency) and how much it varied from note to note (jitter), but measuring by hand is a tedious process, and can be prone to errors.

Miditest lets you measure the performance of your MIDI interface's Ins and Outs.So many thanks to SOS forum user Matthew Skinner for passing on details of a very useful Windows utility for automatically testing the performance of MIDI interfaces and their drivers. The aptly named Miditest 2.2 was written by Evert van der Poll and is a free download from http://earthvegaconnection.com.

First, you connect a standard MIDI lead from a MIDI output port on the interface under test to one of its MIDI input ports, and then (after choosing either DirectMusic or MME drivers and selecting the desired Input and Output device from drop-down boxes) click on the 'Test' button. Miditest then sends a batch of MIDI messages to the MIDI output, collects them again via the MIDI input, and then calculates the time it takes for the signals to travel through the driver software and interface hardware.

This method isn't quite as versatile as mine, since (for instance) you can't use it to measure the playback timing of a hardware synth, but I suspect that most people will be more interested in finding out how tight the timing of their PC-based MIDI interfaces is. The software allows you to decide how many of the simpler MIDI note messages and SysEx data are sent. The latter is constructed in groups of four bytes so that if any SysEx data transmitted from the MIDI Out is not identical when received back at the MIDI In, via the loopback cable mentioned earlier, Miditest can inform you how far it got through the SysEx dump.

Some Initial Results

I'm always a little wary of publishing the results of tests from unknown utilities until I've worked with them for some time, but apart from transmission errors with some MIDI interfaces, the results I've obtained with Miditest so far have been remarkably consistent. The software presents its results in text form, and users can save them, for future reference, as a small 2kb text file. The most important findings are summarised at the top: Maximum, Minimum and Average timings are given for Send, Receive and the sum total of Send and Receive. I suspect that anyone who chooses to test their own setup in the same way will need to do most of their measurements with MME, since many interfaces won't respond when you choose DirectMusic.

For my trusty Yamaha SW1000XG PCI interface, used as a yardstick in previous tests, Snd+Rcv were 0.39ms minimum, 1.20ms maximum, and averaged 0.92ms. Jitter (timing uncertainty) was 0.81ms. However, for some reason the SW1k wouldn't complete the SysEx dump, stopping each time at position 3840.

The figures for M Audio's FireWire 410 were 3.76ms, 3.99ms, and 3.91ms, the round trip lasting about 3ms longer than my PCI results, but with a lower jitter of just 0.23ms. Interestingly, my results for M Audio's FireWire 410 were remarkably similar when measured on both my desktop PC and the Nusystems Clevo laptop I had for review, so it seems that whatever Firewire controller chip and associated motherboard components you have inside your PC, they won't noticeably influence the timings.

I also tried a PCI-based Terratec Phase 88 interface, but although this showed early promise with an Average Snd+Rcv of 1.00ms (very similar to the SW1000XG PCI result), it wouldn't complete the standard MIDI message tests. However, I don't think we can draw too many conclusions from the SW1000XG and Phase 88 errors just yet, since it may simply be that the gap between each message is too small and not really representative of a real-world scenario. For instance, many synths send large SysEx dumps as several smaller chunks of data, each separated by a short time delay, to avoid the small buffers found in some MIDI interfaces overflowing with data. Conversely, you may need to slow down the transmission of SysEx data back to the synth from your PC in the same way, before you can send reliable dumps to some hardware synths (my Korg Wavestation is a classic example). Further tests will probably determine why I got these errors. They may be resolved by sending a smaller SysEx block, and of course they might be an anomaly of the Miditest utility itself.

Nevertheless, Miditest looks like being another very useful tool for determining the performance of MIDI interfaces and their driver software. I'll report back with my future findings, and if any of you would like to send me the results file for your own interfaces (remembering to specify what type and version number of interface driver you're using, as well as what version of Windows), I'll include them in a future round-up of interface performance.