More on hard disk drives

Archived from groups: rec.audio.pro (More info?)

"TJ Hertz" <tjhertz@gmail.com> wrote in message
news:431ddd4c$0$18646$14726298@news.sunsite.dk...
> Quick question - is Firewire (400 or 800) a fast enough interface that it
> would not cause any bottlenecks when used with a fast hard drive?
>
> ie, would my Lacie Big Disk Ultra FW be suitable for use with audio
> applications? I routinely mix with 25-35 audio tracks at the same time
> (let's not get into that!) but am not bothered about 192kHz or anything
> ridiculous, usually just 16/44.1 (though Cubase likes to use 32-bit float,
> does it not?). At the moment I'm just using the Lacie as a backup drive,
but
> I'll switch to using it on projects if it will yield faster performance
than
> a Western Digital IDE drive.

Audio doesn't use much throughput, it's access speed that is most critical,
which has (almost) nothing to do with the interface. Firewire 400 can
manage 50MB/s, or about 600 channels at 16/44.1. Even if you could saturate
the FW400 bus, it would be better to add another FW400 channel rather than
upgrade to FW800. Frankly an archaic EIDE interface (8.8MB max) will work
as well as SATA for most audio applications.

Firewire has advantages over USB 2 since Firewire is self-governing (like
SCSI), where USB requires the CPU to babysit (same with all IDE
derivatives). USB can clog up well before its bandwidth is maxed out since
the CPU has to govern both the interface and the IDE drive, and with the
multitude of frequent read/write changes between audio files it's not a good
idea.

And 32-bit floating-point processing is within the CPU, nothing to do with
the hard drives.

Archived from groups: rec.audio.pro (More info?)

> > Audio doesn't use much throughput, it's access speed that is most
> critical,
> > which has (almost) nothing to do with the interface. Firewire 400 can
> > manage 50MB/s, or about 600 channels at 16/44.1. Even if you could
> saturate
> > the FW400 bus, it would be better to add another FW400 channel rather
than
> > upgrade to FW800. Frankly an archaic EIDE interface (8.8MB max) will
work
> > as well as SATA for most audio applications.
>
> Thanks for the info. So my Lacie, which apparently has some kind of
internal
> RAID configuration (I'm not sure which type) would yield better
performance
> over my internal IDE Western Digital Caviar despite the interface, and use
> less CPU power, then?

It's still an IDE drive in the FW case, so same CPU power. Never mind raid,
it's no better than just shuffling tracks between drives. Assuming your
internal drive is not the boot drive, performance should be the same. Don't
use the boot drive for multitracking.

> > Firewire has advantages over USB 2 since Firewire is self-governing
(like
> > SCSI), where USB requires the CPU to babysit (same with all IDE
> > derivatives). USB can clog up well before its bandwidth is maxed out
> since
> > the CPU has to govern both the interface and the IDE drive, and with the
> > multitude of frequent read/write changes between audio files it's not a
> good
> > idea.
> >
> > And 32-bit floating-point processing is within the CPU, nothing to do
with
> > the hard drives.
>
> Actually, I think Cubase writes 32-bit WAV files by default. Or something
to
> that effect. Winamp and the standard consumer audio players have trouble
> playing them sometimes, anyway.

It should save at whatever resolution you've set it for. It might put
something funky in the header that screws it up.

> It seems to me that for multitrack applications, it would be a good idea
to
> record half the audio files to one disk and half to another, to avoid so
> much seeking between tracks. Is there a configuration, RAID or otherwise,
> that would allow you to do this? From what I gather, RAID-0 would still
> require each drive to look for every simoultaneously playing file, even if
> for only half as much of it. The poor man's solution, I suppose, would be
> simply to transfer half the tracks to another drive and hope for the best?

Cubase probably has a setting to assign tracks on a "round-robin" basis.

Archived from groups: rec.audio.pro (More info?)

Tim Martin wrote:

> No, seeking isn't much of an issue, and hasn't been for a long time.
> Rotational delay can be a bigger problem; for typical access patterns, the
> computer spends more time waiting for the disk to spin round than it does
> for seek head movement.

I remember back in the day of the $500 10 MB hard drive in a PC that
the data was interleaved on the platter and that you could increase the
transfer speed (and apparent computer performance) by finding the
optmium interleaving for your system. (Still) computer guru and advice
columnist Steve Gibson made his name with the Spinrite utility that
optimized the disk interleaving automatically. The interleaving factor
was something that you set during low-level formatting, using Debug.

I guess they decided that interleaving wasn't necessary with modern
speeds. Maybe it's time to take a look at it again?

Archived from groups: rec.audio.pro (More info?)

"Jay Levitt" <jay+news@jay.fm> wrote in message
news:MPG.1d88ddcce05a94ca989904@news-east.giganews.com...

> I'm Pretty Sure I Read Somewhere(TM) that they still do that...

There seems no reason for it any more.

In the old days, data transfers were small, typically one tenth of a track.
Usually, the CPU was not fast enought to issue a read request in the time
between one read finishing and the start of the next block coming under the
read head. So it would take ten disk revolutions to read a track if the
blocks wereread one at a time in sequential order. By interleaving to match
the CPU speed, the CPU could read two or three or maybe more locks per
revolution, so disk transfers speeds for larg files improved.

But sometime in the 1990s, disks started to include buffers. When the CPU
reads a block, the disk itself stores the following blocks to the buffer; so
there's no rotational delay for subsequent block reads anyway, hence no
point in inteleaving. And of course computers have much more RAM thesedays,
and can easily allocate enough to read entire large amounts of data at a
time.

Tim