Reducing "Disc Overload"

[scifunk]

Ok, never had a 'Disc overload' problem before but just been sent a remix project with 40 channels of stems. Is this problem to do with the actual speed of taking the data from the hard drive? Is there anything I can do to to reduce the problem ie buy more RAM? Currently running an 5year old Intel i5 with 8mb (I mean gigs) of RAM, R7, W7.

Thanks in advance.

[Olivier]

I hope thats 8Gig's of RAM..
But yeah.. the speed of the drive may be an issue. If its a relatively full disk, and its not an SSD, then try defragging it. See if that wins you some speed.

[Raveshaper]

I have disks running in Raid 0, 7200 rpm drives less than a quarter full, 8 gigs ram, quad core, still gives me overloads when working with stems.

I'm curious why audio isn't loaded into ram to prevent this, but I'm far from a computer scientist. I'm sure there's a good explanation for it.

[scifunk]

It's a bog std Seagate drive 7200rpm, 500mb about 70% full and recently defragged. Is it worth getting an SSD drive for this type of project?

I thought stems would be a lot easier to handle than trying to compute synths and fx in real time?????????????

[Raveshaper]

The reason the disk is showing overload is because the program is spooling the audio off of the drive by accessing the sound files instead of preloading them or buffering chunks into ram. Near as I can tell.

If this isn't true, I'm sure selig, Scuzzy or other power users will correct me. I'm curious what the straight story is on this behavior myself.

[kloeckno]

It almost always shows the overload signal when scrubbing the playhead around the timeline, so I wouldn't worry too much about it until it's actually lighting up a lot.

[jam-s]

Let's make an estimate calculation here:

Reason stores its audio in 32bit floating point (max), so

IO_in_bits = sample_rate * bit_depth * number_of_tracks

IO_in_byte = sample_rate * bit_depth * number_of_tracks / 8

So here IO_in_byte = 44100 * 32 * 40 / 8 = 7056000 byte/s = ~6.73 MB/s

Even a quite old hdd should be able to get this IO on sequential reads, but as all stems are read in parallel I guess it's much more likely to be random access reads, unless Reason is using much RAM for serious prefetching.

[ScuzzyEye]

Is the light coming on and staying on, or just blinking when you jump to a new location? Even with a 4-way striped SSD, I see the light when I scrub the play head. Reason just doesn't cache all audio into memory. It shows the indicator when it has to go dump its current buffer, and load something else. It probably likes to hold a few seconds of audio in memory, so any slow down in reading can be handled. But after it's discarded what it thought might come next (read-ahead cache), the buffer is below what's considered the safe threshold. So the light comes on until the buffer is refilled.

Unless the light is staying on all the time during playback, I wouldn't worry about it. If it is staying on, you need a faster drive to counter it. RAM and CPU are not involved in this case (well RAM could be indirectly, if you don't have enough, and your computer is swapping to the same drive as your audio data, so it's spending a lot of time swapping, and can't get to the audio steam in a timely manner).

[jengstrom]

The audio tracks in Reason are streamed to RAM continuously based on the play marker position and some other factors.

@QwaizanG: Reading directly from disk would never have a chance to work.

The disc overload light is more likely to light up while the calc meter is running, since that means Reason is also writing HQ stretched/resampled audio and/or waveform LOD to the scratch disk.

It means the disk is reading a bit slower than expected on average, and it should only matter if it causes dropouts in the audio, which you will hear. It can't affect bouncing or exports, only realtime playback.

[scifunk]

It was stopping playback altogether. I've now cut out the silent parts of the stems and managed to delete a few and it's running much better. Thanks for the replies. Think a PC update is on the cards at this rate.

[Vyckeil]

The best way to avoid such problems is having your stems/audio files on a separate HDD from the OS (even an external one works), or having an SSD.

HDDs running the OS have their IOPS reduces because the read/write head is all over the place trying to run the OS in the background (think of a vinyl player moving its head all over the record). I don't know about other OSes, but I know that Windows constantly read/writes 4 kilobyte files and the head tries to operate the OS while reading the audio files. This is not a problem for SSDs because they don't have heads moving around, they simply read/write from the NAND flash chips and excel at read/writing 4k files compared to traditional HDDs.

Hope this helps.

[scifunk]

So just save your song file to a different hard drive and work from that as your main on?

[ScuzzyEye]

So just save your song file to a different hard drive and work from that as your main on?

That may be the easiest fix, especially if your machine is swapping. Don't forget to also point your scratch space to a temp folder that other drive.

[mcatalao]

Guys are right, write and read speeds on hard-drives, are so high (we're talking about 60 to 200 MBs), that should not be a problem. I've had test files with 400 stereo tracks, with no trouble reading from them, on a SSD - a 500 MBs write and read drive, and a couple hundred with normal HDD's. My tracks often go up to 40 to 60 tracks and I've never had hdd issues.

Anyway, my guess, is that you might have something i the background, like an Anti-Virus app, killing your resources (Ram, HDD, etc).

Good Luck!

[Exowildebeest]

I would also recommend running your OS on a separate physical drive from your audio projects.

Running from an external USB drive I wouldn't recommend, those drives are usually meant for data storage, not fast reading.

[jam-s]

With USB3 an external drive almost feels like an internal one, still the internal drive is the less risky option as no one can unplug it as easily by accident.

[gak]

Long story short, I have two SSD's. Originally, I had a 7200 drive for audio on this computer, but got a 256'er evo 840 for about 80 bucks and replaced it. So I still use the "separate drive" for audio/projects but it's just to help the main drive from not having so many writes. 

Whatever new comp you/whoever gets, please do yourself a favor and research/buy SSD. You CAN'T understand the speed diff until you've experienced it (seconds for a boot, nice fast project loads) 

[tobypearce]

In my opinion Reason, since version 8 and certainly in version 9, experiences these kinds of problems when there is more demand on the graphics element of the program. I was having a section of a track that was running into disc overload and stuttering very badly. I minimised the rack (not the sequencer or mixer) and the problem disappeared totally and instantly.

I happened to have an instance of Spectrum running at the time in the rack as I was checking frequency responses, but it seems to do it with other visual intensive changes too, such as zooming in or out multiple times (i.e. pressing g or h in quick succession).

I don't recall this happening in version 7. I think there's some kind of issue.

[househoppin09]

tobypearce, what OS are you running? A lot of people have reported things like that on Mac, which can generally be circumvented by turning off hi-res graphics (somewhere in OSX's properties for Reason or something like that, I think). If you're on Windows, which version exactly? I keep hearing different things about whether or not there really is a performance drop in Windows between Reason 7 and later versions...

[tobypearce]

Mac for me.

[MitchClark89]

tobypearce, what OS are you running? A lot of people have reported things like that on Mac, which can generally be circumvented by turning off hi-res graphics (somewhere in OSX's properties for Reason or something like that, I think).

i would love to know more about that. am currently googling it. if you have a reference i would be grateful

[househoppin09]

See this thread: viewtopic.php?f=4&t=7495442. In "get info" for the Reason app, there should be an option to disable hi-res graphics.

[MitchClark89]

See this thread: viewtopic.php?f=4&t=7495442. In "get info" for the Reason app, there should be an option to disable hi-res graphics.

thank you for the help man. i just now realsied i dont have retina display so it doesnt work for me. sorry about that but thank you