Reply
 
Thread Tools Display Modes
  #1   Report Post  
TJ Hertz
 
Posts: n/a
Default More on hard disk drives

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


  #2   Report Post  
Zigakly
 
Posts: n/a
Default


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


  #3   Report Post  
TJ Hertz
 
Posts: n/a
Default

"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


  #4   Report Post  
Zigakly
 
Posts: n/a
Default

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.


  #5   Report Post  
Tim Martin
 
Posts: n/a
Default


"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




  #6   Report Post  
Mike Rivers
 
Posts: n/a
Default


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?

  #7   Report Post  
Jay Levitt
 
Posts: n/a
Default

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
  #8   Report Post  
Tim Martin
 
Posts: n/a
Default


"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


Reply
Thread Tools
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Changing Fuse in Mackie Hard Disk Recorder [email protected] Pro Audio 16 August 10th 05 10:43 PM
USB 2.0 Hard drives for audio? WillStG Pro Audio 3 January 13th 05 04:38 AM
stand alone hard disk system vs computer based system paul tumolo Pro Audio 7 December 7th 03 03:35 AM
for sale: vf-16 hard disk recorder Aaron Anodide Pro Audio 0 September 25th 03 03:05 PM
Two hard drives or two Partitions...which Laurence Payne Pro Audio 4 July 9th 03 07:53 PM


All times are GMT +1. The time now is 05:54 PM.

Powered by: vBulletin
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 AudioBanter.com.
The comments are property of their posters.
 

About Us

"It's about Audio and hi-fi"