This question comes from the problem I’m having with disk overload.
It looks like Cubase is still uploading chunks of audio directly from HDD as it runs?
WHY???
Why not load the whole project (WAV files) in RAM? It’s not 1998 anymore, we have enough RAM these days… My PC is pretty low-spec on RAM, only 16Gb, but I’ve never had a project that was more than 1Gb as seen in file manager (including all the unused takes). A single patch from Omnisphere is bigger than my whole project I’m mixing!
It does load VSTi into RAM, but it won’t load WAVs (which are like 1/10th or less in size at most in any project)! WAV load size is pretty much negligible!
So now I’m having an issue with HDD overload because apparently Cubase is still reading the wav files on the go. My RAM is utilized at like 10%, it sits empty while Cubase is stuttering trying to read simultaneously 30 wav files from the HDD that only take up like 300Mb total, but it just won’t load them up. So any time I rewind, it stutters again because it doesn’t keep anything in RAM.
If things were in RAM latency and buffers would be irrelevant.
To me it seems SO DUMB. But maybe I don’t know something? Why is it NOT dumb? Is there a reason we can’t have projects loaded entirely in RAM?
It does use RAM to hold audio files. If you have unused RAM, the OS will employ it as a disk cache. Any subsequent reads of those audio files will be served from RAM and not require disk reads. If you’re stuttering, either the problem isn’t access to those audio files, or you don’t have enough unused RAM to hold those files. Even if you aren’t using RAM to hold the files, disk access is rarely a bottleneck these days, due to widespread use of SSDs.
I would suggest that your setup is in need of tweaking, if we knew your setup we might be able to help, I have only 12 gig RAM and never have disk problems.
Regardless of if, when, how Cubase uses ram for audio files, there ARE reproducible issues with the playback engine.
If you have an audio part that is both warped and heavily chopped (such as a drum performance), I guarantee you that it will often not play back correctly or consistently.
You will see specific areas that it struggles to play, and these are always accompanied with spurious HDD read activity in the meter.
How can you “guranatee” that your issue will also appear on our setups? It does not. (Also not with warped and chopped drum performances).
Maybe a Mac issue?
That’s what is going on. Why is it programmed to be that way? It’s beyond me…
I’ve never had a problem with disk overload until recently when I was working on a song that had a background vocal recorded repeatedly on a loop, vocalist sang the same part 5-10 times in a row recorded as a single file. I then split all these takes into separate channels as individual parts (for choir effect) but basically all these parts came from a single wav file.
Technically, the workaround is to render each part, but I’m just shocked that such an archaic way of handling audio still exists in 2020 now that I’ve thought about it.
HDD should only be used when loading the project and only during recording. It should not be touched during playback. Ever. Everything should be in RAM, 100% of the time.
I’m not sure that this is a ‘reading from HDD’ issue as it can happen on small sessions running from an SSD that should be able to handle hundreds of tracks of audio without breaking a sweat.
Cubase IS using RAM to buffer some or even all of the audio, so when the HDD meter goes crazy we shouldn’t presume its a reading issue. That meter does some pretty weird stuff at times - for example sometimes when you stop playback it parks itself in the red. Why?
I’ve been excessively chopping and warping audio in Cubase for decades without a problem. These issues have appeared in the last couple of years so I suspect that its simply systematic of an issue with the underlaying audio engine -
Maybe the recent versions of elastique / variaudio, or the preference to automatically create warp markers for all audio?
This is yet one more issue I can’t be bothered to hunt down the cause of. As said above, simply bouncing to a new audio part makes it go away.
audiofiles are and should be streamed. Well unless the DAW is intelligent enough to use unused RAM as a Dynamic buffer.
Normally this is not an issue, even a spinning rust drive @ 7200 rpm can handle hundreds of audio files played back at the same time. With a SSD that increases a lot.
Bouncing can help, and is sometimes necessary.
If only 30 audio tracks gets you disk overload, then there is something wrong. That low amount of audio tracks can easily be streamed from a USB2 drive. What the problem is causing this behavior? Lots of possibilities, driver, background task etc…
If you’ve not seen this happen then you won’t appreciate the issue - this IS a Cubase problem because when it happens it is 100% repeatable as if its a corrupted bar, so background interfearence, drivers etc can be ruled out. When it happens, that bar will not play back correctly ever - not in the mix or as a single soloed track.
I’ve seen this happen on perhaps half a dozen sessions a year for the last couple of years.
i Have seen it a few times, but have been able to fix the problem. First thing to try is bouncing the tracks with heavy editing. I also have disabled the Auto Hitpoint detection in the preferences, that reduces the disk activity by not automatically scanning any new audio. I do it manually when I need it, but that of cause depends of your workflow if that is something to try.
I have had a driver issue with Win10, it defaulted to a MS driver after a Win10 update, but I think that has mostly to do with my old hardware. I manually updated the drivers with newer Intel drivers and things where back to normal.
Oh and when I forgot that I had a disk image backup scheduled and try to use a heavy project at the same time, man I can be dumb some times
HI
The Cubase library is saved in two places, C: \ User \ name \ App Data \ Steinberg \ Content, and C: \ Program Data \ Steinberg \ Content. Can both entries be transferred to the disk, e.g. D: , keeping the access paths but on the D disk?
