does it WORK?


How I discovered that I never have to buy expensive, problematic SCSI drives again, to successfully record digital audio.

Ok, so this is quite an old article. I'm leaving it up, because it gives good background on a historic discovery in my personal evolution through learning about digital recording and file/data handling. Since this article was written, there have been great strides made in the field of data storage and processing: SATA technology has come along, and has greatly improved the speed at which these principles work. The cost of SATA adapters has dropped to a very affordable level, making it possible to provide this solution much cheaper, and much faster, than it was when I got into it. Now, for the history behind it all...

Ever since computers became a tool in processes of recording digital audio, we have had it drilled into our heads that SCSI is the only way to go for storage. And until recently, that was true. However, advances in implementation of technology have made it more than feasible to use cheaper (and some would argue, even more efficient) EIDE/ATA hard drives.

Issues with SCSI Voodoo

Everyone who has ever dealt with adding SCSI peripherals has learned that SCSI inherently means that you will have to sort through issues of cabling and termination, as well as host configuration, which can be a real headache. Even when everything seems to be tweaked and working, if you change anything in your setup, you're dealing with a whole new ball game, which can take a great amount of (non-billable) time to sort out. I was no exception. When I interfaced a third SCSI device to my Initio Miles2 LVD SCSI host, I found after a rather lengthy battle, that to even get my computer to boot up again, I had to spend an additional $148 for a Granite Digital cable. Mind you, the first two devices worked just fine before adding the third device. Each of the three devices would work fine on their own, but all three together added up to an unworkable situation, until I spent more money for a lousy little stretch of wire. In addition to the headache, this meant lots of downtime.

Imagine how thrilled I was to find that I didn't need to worry any longer about issues of termination and expensive cables, and other elements of "SCSI Voodoo."

a remedy:

On this page, I will chronicle my steps in arriving at my findings. To be fair, I should warn you that first of all, I am NOT a technically minded person. I am a "real world" experience sort of guy. I just know when something either WORKS or doesn't. When something doesn't work as I know it should, I am capable of doing a great deal of trouble shooting, but one of my greatest strengths is knowing when it's time to turn to someone more technical than myself, and to say "HELP!" Therefore, if you are looking for a technical explanation of how all this works, you aren't going to find that here. What you will find here is a real-world explanation of what WORKED for me, and how I got to this point.

A friend told me that he had been reading about many people who were discovering that it is feasible to use ATA drives for recording digital audio. I was not easily convinced. This friend put me in touch with a fellow I'll call Egan (mainly because that's his name), who was a strong proponent of ATA over SCSI. Egan and I had quite a long exchange of email notes, discussing the ATA vs. SCSI solution. I have to say that he went above and beyond in extending patience to put up with my seemingly endless questions and doubt. Now, Egan IS technically minded, and much of what he had to say was way over my head. He went on and on with mathematical calculations designed to convince me that an ATA drive was indeed capable of the kind of track counts, even at high bit rates, that I work with. I won't go into quoting him here, but he finally convinced me that I should just TRY running some audio files off the boot drive (which is an ATA drive) of my G4. I copied a song file from the 10K Cheetah Ultra2 SCSI drive (which I was using at the time) to my startup ATA drive. I picked a song which had something like 36 tracks of 24bit audio, and moved it over to the startup ATA drive. And to my great surprise, it played back just fine (I had always heard that it was a real no-no to attempt to run audio from the boot drive, no matter what type of drive it happened to be). So, I then armed a few tracks, feeling fairly confident that if I tried to simultaneously record new audio and play back 36 tracks of existing audio utilizing my boot (ATA) drive, then SURELY it would fail. Right? Well, it DIDN'T fail... it handled this task just fine.. ON MY BOOT DRIVE, mind you!! Ok, so Egan, the technically minded ATA proponent, finally had my undivided attention.

Egan sent me his formula for figuring the theoretical track count from any given drive configuration. I am posting that formula on Page 2.

Because of what I had always been told about SCSI being the only option, I wanted to be completely sure that if I were going to take "the chance" of going the ATA route, I would not run into a situation where my storage solution would run out of capability to keep up with my demand for a high track count, and for adequate performance. So, I started researching another old standard saying that had been drilled in over the years: that being, if you want greater performance, then you have to RAID multiple drives. I began wondering, if ATA drives will handle digital audio recording, then what about putting them in a RAID array? What I found is that RAIDing ATA drives by way of SOFTWARE solutions yields virtually NO benefit, other than creating a larger volume. 'Why' this is, I don't know, and so I can't attempt to explain: remember, I'm not a technical guy. I just know when something either works or doesn't.

In conducting my research about ATA/RAID, Egan pointed me to a great resource. Mike Breeden runs an excellent and informative web site at There are loads of pages on his site which hold loads of information on topics of SCSI, ATA, Processor Upgrades, and other topics of great interest and value to anyone who uses a computer for anything more than playing Pong. One article which was linked to from his site turned out to be very informative on this topic of ATA/RAID, and I suggest you read it, if you are at all curious about this solution. It can be found here. This article (as well as others) show that while SOFTWARE RAIDing ATA drives does not yield better performance, HARDWARE RAIDing them CAN!

a remedy:
how I got there

Here is the step by step guide to my implementation of the ATA/RAID solution.

First of all, here are the relevant details of the machine on which these tests were run:

Images of each benchmark result are on the second page of this report (there is a link to the second page further down).

I purchased two Maxtor model ST060H6 7200rpm 60GB ATA/100 drives (slightly over $200 each). Do your own research to determine which drives you want to purchase (the xlr8yourmac site has a Drive Compatibility database which might be helpful here).

One note on the Maxtor drives I selected: For some reason, Maxtor designs these drives in such a way that when they are first installed, they do not perform WRITES at their full capability (while READS are fine, right out of the box). Maxtor claims that this is a "feature," although I don't know their reasoning. Maxtor states that the drives need to go through at least ten full power cycles (Shutdown/Startup, not simply Restart) before they really are ready to go. I found that I had to do seventeen power cycles (checking with SpeedTools each time) before my drives "opened up" their Write performance. Your mileage may vary.

I first hooked up one of the Maxtors as the Slave drive on my Apple internal ATA bus, formatted it as one HFS+ partition with Apple's DriveSetup v2.0.3 (which installed Apple ATA Driver 3.2.6), restarted and then ran ATTO ExpressPro-Tools 2.5 to benchmark performance. I repeated this formatting process with Intech Hard Disk SpeedTools 3.2, which installed HDST ATA Driver 3.2.1.

Then, I installed a Sonnet Tempo RAID66 PCI card in my computer. It should be noted that there are two similar cards which Sonnet markets. One of them does NOT provide hardware RAID capability, while one does. Make sure when you order, to specify the RAID version, if you ever intend to do a hardware RAID. I purchased mine for $198 from MacGurus, but they are obviously available from a wide variety of sources.

A note about MacGurus: These guys are the MacDaddy resource when it comes to dealing with SCSI issues. Their message forums are an invaluable source of info if you are stuck in SCSI Voodoo Hell. You can submit your problem and receive help from people who really are honest-to-goodness SCSI Gurus. However, I will warn you that if you contact them with questions and/or an order for anything other than SCSI devices, they will most likely try to talk you out of it (they still subscribe to the old belief that "SCSI is the only way to go").

This Sonnet card appears to be manufactured by a company in Taiwan, called ACard. ACard makes this card and allows Sonnet (and a few other companies, I believe) to market it as their own product. Even though the card itself says "Sonnet," Apple System Profiler sees it as an ACard. I don't know if there is any huge difference (or any at all) in the firmware for the Sonnet version vs. the ACard or any other version. When I asked, Sonnet instructed me that I was NOT to attempt to install the ACard firmware, and Sonnet doesn't even seem to make their firmware available for download. They just say that the card already has the latest version. Ok. That's fine until I NEED to flash it for some reason. Guess I'll cross that bridge if I come to it.

After installing the Sonnet card in a PCI slot, I connected each of the two Maxtor drives to it with the two 40-pin/80-wire Ultra ATA/66 cables which were included with the PCI card. Each one was jumpered as Master, and each was on a separate ATA bus. This card provides 2 busses, making it possible to add four additional ATA drives to your G4 - two Masters and two Slaves. At this point, each of the Maxtors were operating independently of the other - they were not yet striped as a RAID volume. I reformatted each of the drives, because when they are connected to the Sonnet card, the System sees them as SCSI devices, not ATA. So, they need to have a SCSI driver. I then captured benchmarks for one of the drives connected to the ACard, just to compare its performance there as compared to when it was on the internal ATA bus. It showed better peak Reads and Writes, yet the sustained performance remained roughly the same. Just for the sake of experimentation, I measured performance while the drive had every different SCSI driver I could get my hands on, including Intech HDST SCSI driver 3.2.0, SoftRaid driver 2.2.2, and ATTO driver Rev. 2.5.1.

Then I flipped magic switch number two on the ACard to put the drives in striped RAID level 0 mode. Upon powering up the computer then, the drives did not appear on the Desktop, so I had to go to DriveSetup, select the volume, and initialize it. Then the volume appeared (being made up of the two Maxtor drives) as one drive on the Desktop. A 114GB volume. That's a nice big volume, but, how would it perform?

WOW!! I benchmarked it (see figure 7), and was thrilled with the results. Better sustained Reads and Writes than I ever got with my 10Krpm Cheetah Ultra2 SCSI drive!

Figure 7. Maxtor volume / Sonnet ATA bus / RAID 0 / Apple SCSI driver 8.1.4

I repeated the Benchmark routine with different drivers installed, just to see what sort of a difference I would get. There were slight differences, and some readings were faster than the Apple driver, but in the end, I opted to go with the standard Apple driver, just because I know that one will always (at least one can HOPE) be compatible with whatever System version I happen to run. Again, I performed the test with Intech HDST SCSI driver 3.2.0, SoftRaid driver 2.2.2, and ATTO driver Rev. 2.5.1.

It should be noted that ATTO warns that their driver is not compatible with disks in this kind of configuration. I was feeling rather spunky by this point and decided to try it anyway. I installed the driver and ran a test before restarting. It's interesting that this driver succeeded in producing slightly better results than any other driver I tested in this mode, but I was unable to get the machine to restart with the ATTO driver installed on this striped volume. I then had quite a bit of messy work to do to get back to Oz. But now when ATTO says their driver is not compatible with something, I'll KNOW not to attempt to force a square peg in a round hole again. Word to the wise. Kids, do NOT try this at home.

performance with audio

where the hard drive meets the road (?!)

So, being thrilled with the results on the bench, I decided to see what sort of real-world performance this new beast would give me, running audio off of and onto it. I copied a song file over to the new RAID volume and opened it up (in Logic Audio Platinum 4.7). This particular song was comprised of 34 tracks of 24bit, 48KHz audio, and I was using quite a few labor-intensive plug-ins (Compressors, Gates, Reverbs, Delays) and lots of eq across the console. It played back without a hitch. So, then I armed twelve new tracks (fed with the analog inputs from my MOTU-1296) and put the song in Play. As it was rolling, I threw the 12 new tracks into Record. Smooth. It rolled all the way through the song that way with no problems. Then I armed 12 more new tracks, and threw them into record as I was playing the existing 46 tracks. Not a hitch. So then I was able to play back all 58 tracks without a problem. I have to mention that even at this point, the Disk Activity Meter in Logic was showing noticeably less of a strain than it did when running the original 34 tracks off the Cheetah.

Next, I wanted to make absolutely sure that I would be able to maintain this disk array properly, without loosing data when a problem comes up. So I ran DiskWarrior 2.1 to rebuild the directory data on the volume. It performed that task flawlessly, as it should. I ran FileBuddy 6.0.6 to rebuild the desktop file on the drive. Again no problem. I then ran my 58 track song again and just sat back and marveled. Who says SCSI is the only way to do digital audio? Certainly not I, anymore, that is.

I haven't tried to find the "real world" upper track limit on this RAID setup. However, Egan has sent me his formula for calculating the theoretical track limit for any given drive configuration, and I am posting that formula on Page 2. Ahhh, I'm a happy man.

To view images of all the benchmark results mentioned in this presentation, go to Page 2.

If you have been helped by the information and/or services which I provide, and feel compelled by an overwhelming urge to send some form of thankful compensation, I DO accept totally free-will donations. Just click here.

Click to win a free tape drive!
Click this banner for info on the Ecrix VXA-1 backup tape drive kit,
probably the BEST tape backup solution anywhere.
33GB uncompressed / 66GB compressed!

Go to jb's home on the web.

Visit his discography.

Visit his equipment page.

This page was created with Adobe GoLive,
and was proudly MADE ON A
NONE of Bill Gates' software.

Mac and the Mac logo are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. The Made on a Mac Badge is a trademark of Apple Computer, Inc., used with permission.