@ 88.2Khz/24bit....system maxing out....cures?

[kudzu]

Running Logic 6.4.2 on a G5 dual (3.5 Gb ram).....24 + tracks @ 88.2Khz/24bit....as soon as I start editing "system overload" error message appears ( f*ckin annoying).....now the CPU is hardly working....the problem is the HD. I have the 160Gb HD that came with the G5 and an internal seagate 400Gb drive (Logic's on the 160Gb system drive, All audio files on 400Gb drive)....both are spinning @ 7200rpm....I've bought a 10,000rpm drive to try and solve the problem....someone somewhere suggested I should take out the 160Gb drive and swap it with the 400Gb as the system drive with the 10,000rpm drive for audio....any thots guys? much appriciated

[jdunn]

kudzu - See the thread about "Fibredrive" in the High End. I'm starting to think that's the answer. $2,000, but peace of mind may be worth it.

[wilcofan]

I did lots of drive tests on Logic 5.5.1 on PC and Mac a couple of years back and your bottleneck is no doubt the drive @ 88k/24bit.

24 tracks sounds about right on a 7200 rpm drive.

Rotation speed was the cure for my 88k sessions. I moved to 15k and now I'm getting 40-50 tracks @ 88k (although I'm not on Logic anymore).

I just think 7200 is never going to cut it on an 88k session without stress.

[max cooper]

Originally Posted by wilcofan

I just think 7200 is never going to cut it on an 88k session without stress.

You think a RAID would get you there?

[zabour]

Originally Posted by max cooper

You think a RAID would get you there?

That's the same thing I was thinking ... would an array be better and less expensive than a faster drive. But I would suggest only trying an array with hardware raid controller, a soft array will eat up your CPU when you need it most as you are streaming and applying real time effects.

[wilcofan]

RAID will improve your seek time of MORE data but it won't increase your fastest seek time. This seems to be the bottleneck with higher sample rates. Two drives with 7.5ms seek times still need 7.5ms to reach the data it's looking for. This is not increased by having two drives. Throughput is not really the issue with 88k recording, one thing that improves with RAID.

The initial access is what's going to keep errors from popping up. This is what the 3ms seek times of 15k drives bring.

[dkatz42]

Originally Posted by wilcofan

RAID will improve your seek time of MORE data but it won't increase your fastest seek time. This seems to be the bottleneck with higher sample rates. Two drives with 7.5ms seek times still need 7.5ms to reach the data it's looking for. This is not increased by having two drives. Throughput is not really the issue with 88k recording, one thing that improves with RAID.

The initial access is what's going to keep errors from popping up. This is what the 3ms seek times of 15k drives bring.

The biggest bottleneck is all the seeking between track files (the more tracks you have, the more seeking.) As you point out, the time for the initial seek isn't improved with RAID, but it's also not all that interesting; what gets interesting is what happens when things get rolling. A combination of the drive controller, the o/s, and the application do read-ahead on the files (trading RAM for time) so things become statistical in a hurry.

The optimal solution would be for the DAW software to spray track files across multiple drives. DAWs are unusual applications in their need to read from many files at once, with realtime constraints.

RAID is really helpful when the data rates are extreme, such as video editing. DAWs just don't suck that much data (64 tracks of 24/96 runs about 18.5MBps) but they gather it from many places. RAID can potentially help some, but "striping" between drives on a per-file basis would be better.

A really low-cost way to improve things is to tell your DAW application to use the largest disk buffers possible. This in no way should affect audio latency; it just means that the application will take an extra couple of milliseconds to get started when you press the button, and will use more RAM, but becomes more tolerant of seek latency. The amount of extra RAM used is in the noise in comparison to anything else you do.

[jdunn]

So in short, seek time is an important spec.

Good tip on the RAM buffer settings. thumbsup

[NuSkoolTone]

Also, I don't know if they do this on macs, but make sure your files are defragmented on your audio drive so they are continuous files. I can't stress this ENOUGH! It's a LOT easier for a computer to find the beginning of ONE file and read it vs. reading the beginning of ONE segment of the file, then ANOTHER and ANOTHER etc..... One way of cutting down (well, optimizing anyway) the seek time is reducing how much it has to seek for

[kudzu]

Originally Posted by dkatz42

The optimal solution would be for the DAW software to spray track files across multiple drives. DAWs are unusual applications in their need to read from many files at once, with realtime constraints.


A really low-cost way to improve things is to tell your DAW application to use the largest disk buffers possible. This in no way should affect audio latency; it just means that the application will take an extra couple of milliseconds to get started when you press the button, and will use more RAM, but becomes more tolerant of seek latency. The amount of extra RAM used is in the noise in comparison to anything else you do.

Great advice dkatz42.....I only have two drives in the G5, do u mean if I spread the data needed for an arragement between both drives things'll improve? I don't know much about raid setups......Also, at high sample rates the latency reduces when @ high buffer settings (1024 +).....I forgot about this....ta 4 the heads up..... thumbsup

[dkatz42]

Originally Posted by jdunn

So in short, seek time is an important spec.

Yes, and increasingly so as the track count goes up. With a handful of tracks it probably doesn't matter that much (but with only a handful of tracks, not much matters.)

Originally Posted by kudzu

I only have two drives in the G5, do u mean if I spread the data needed for an arragement between both drives things'll improve? I don't know much about raid setups......Also, at high sample rates the latency reduces when @ high buffer settings (1024 +)

Yes, things should improve, assuming that the drives are similar in specs (seek/transfer rate) and assuming that you're actually seek-limited. I don't imagine that most DAWs care where the files live when played back. Logic only allows you to specify one location for track files when recording, but I imagine it would be possible to move the files around and let the Project Manager glue things back together. It would be nice if the DAW vendors let you specify a set of locations for recording.

RAID level 0 does "striping" across multiple disks at a much more microscopic level. Successive chunks of a single file are spread across multiple drives. This helps when you have a lot of data coming out of a single file at really high speed, since you can be reading from one drive while another one is seeking, thus reducing the wait time for the next chunk of data. With a lot of files the advantage is lost, because each drive will still be seeking across 64 locations if there are 64 tracks, for example. (Each drive doesn't have to seek as far, because there is only 1/N of the data on each drive, for N drives, so the data is more compact. But the cost of moving the heads is not linear with distance; moving half of the distance still costs more than half of the time.)

In the 64 track case, spreading the files across two drives means that each drive needs to seek to only 32 locations, for example.

I'm not sure about your comment about latency. It sounds like you're talking about audio interface sample buffer size, which is essentially independent of the disk issue (it affects whether the DAC underruns, and directly impacts audio latency, whereas disk buffering affects disk underruns and has no impact on audio latency.)