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.

Thanks

TJ

"TJ Hertz" wrote in message
...
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.

"Zigakly" wrote in message
...


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?


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 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?

Thanks

TJ

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.

"TJ Hertz" wrote in message
...

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.

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. But for large files, that shouldn't be a problem
either ... you'll generally be reading pretty much all of each track.

Probably the most important thing is to avoid getting your disk more than
say 75% full. That way, the file space allocation algorithms will be able
to store the data in such a way it can be retrieved fast.

Tim

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?

In article .com,
says...
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.

Hell, we used to do that on Commodore floppies - except that there, the
serial interface was the bottleneck, so that you had to interleave based
on how long it took to transmit the sector to the computer. (Cue "I
once created a database entirely from ones and zeros" cartoon.)

Problem was, once people figured out how to write fastloaders that used
the clock wire as an extra data bit, the timing was now off, and all
your 'interleaved' floppies were now slower than the regular ones...

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

I'm Pretty Sure I Read Somewhere(TM) that they still do that... but
again, with random access, there's no predicting what you're going to
read in what order, and therefore no particular interleaving pattern
that will help.

It's the same reason defragging doesn't help (much) for audio drives.
You can put a single file in order, but you can't possibly lay out 40
tracks in some fashion that's optimal for reading them back in
simultaneously unless you know the exact patterns of the application
that will read them. And even then, adding another track would screw it
up royally.

--
Jay Levitt |
Wellesley, MA | I feel calm. I feel ready. I can only
Faster: jay at jay dot fm | conclude that's because I don't have a
http://www.jay.fm | full grasp of the situation. - Mark Adler

"Jay Levitt" wrote in message
...

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