So I’m not sure how long this has been an issue but I feel like it started around when I got Cubase 12 maybe a little earlier but I have no idea where to start to fix this. Every time I play, stop or click and drag on the loop bar the disk cache will immediately spike and also cause a drop out of audio for a few seconds.
If anyone has any advice on how to fix this that would be great.
these are my specs for Reference
Operating system: Microsoft Windows 10 Pro (10.0, Build 19044)
Processor: Intel(R) Core™ i7-8700K CPU @ 3.70GHz 6/12
Motherboard: ASUSTeK COMPUTER INC. ROG STRIX Z370-F GAMING
RAM: 32 GB
Hard disk1: Samsung SSD 860 EVO 1TB (931.5 GB/Fixed hard disk media)
Hard disk2: ST2000DM006-2DM164 (1.8 TB/Fixed hard disk media)
Graphics card: NVIDIA GeForce GTX 1080 Ti (11 GB)
Shows the hard disk transfer load. Disk Cache Overload
The overload indicator to the right of the disk indicator lights up if the hard disk does
not supply data fast enough.
If it lights up, use Disable Selected Tracks to reduce the number of tracks playing
back. If this does not help, you need a faster hard disk. To reset the overload indicator,
click its display. In the Audio Performance category of the Key Commands you can
also assign a key command for this.
This issue starts as soon as even one track is placed into the session regardless of plugins or anything it just always spikes. I tried to move it to my SSD and still, the issue persists. do you think this could be from the fact I’m dragging sounds from an external HDD?
How did you ‘move’ the project? Copied the folder using the explorer? If so the project file is still reading files in the original location. You should either delete the original or a better option is to do a ’ back up project’.
I don’t think so, except if the disk is ancient, ready to die, usb1 connection, and reading tons of stereo tracks at 182Khz/32bit.
I would say create a new project on your SSD, record a couple of tracks there and see if the problem persists. Then you know if it is an actual disk problem.
An SSD will be fast enough for samples and project files simultaneously.
Data requested for every second are still not much for the read speed of an SSD.
Traditional ssd’s usually have a read time of around 500MB per second.
A stereo 96Khz/24bit Wav file has a file size of 576KB per second.
So (theoretically) with a traditional SSD you are able to playback around 1000 stereo tracks of 96Khz.
For lower bitrate, you would get higher disk performance.
For mechanical drives (HDD) you can do the math.
What do you mean dragging sounds, for what?
Keep in mind:
if you use a soft sampler for your samples then its a ram load
if you use something like kontakt’s “direct from disk” feature then disk gets in the game
if you treat your samples like regular audio material then it is disk load
if you use i.e. soft synths with large audio banks then its a ram load (disk and cpu do matter but still)
yea I thought that just moving it from drive to drive would fix it but guess not. however, I just tried starting a new project on the SSD as you said and it actually made a difference. The asio guard didn’t appear to have any load on it at all and the pause between pressing play and actually playing has gone as well as the disc cache spike upon playing which was the main issue that was bothering me. it however still spike up when pausing and moving the play head but that’s less bothering than the delay that existed when starting and stopping the track so thank you for the advice that’s really saved me half a headache.
yea that’s how I was running it before but it seems to be working better from running the project on the same drive that Cubase is on so ill just run with it for now and move projects when I’m done with them I guess.
Well, if the external HDD was USB 2, then it would hardly go past 60 MB/s (assuming the USB bus isn’t used by another device), and this is on one single file read !
A DAW has to read the audio files continuously, so imagine if the computer has to read 30 files at the same time, the maximum transfer speed for each file drops to 2 MB/s (which is still okay for most formats), but most importantly, if the HDD cache is too small, the head has to move back and forth frequently to seek for each file, which kills the read speed even more. And in the most severe case, if the files are too big, the HDD won’t be able to deliver data fast enough and playback drops.
USB2 is 30mb/s max and that is under ideal circumstances, reading one large file (I have seen USB3 speeds up to 350MB/s, with external sata ssd). I think the only reason that a slow disk like that seems to work is that windows caches disk access. So after one go, everything is read from ram (cache). I tested my internal HDD of my internet computer (not DAW, ssd only), which reads and writes 90MB/s, but reading small files it drops to 10mb/s, usb will be much worse.
Well I have never seen anything go beyond 30MB/s, but your math is correct of course. For fun I just tested. An external ssd that can do 300MB/s on usb3 does 25MB/s on ausb2 port. An external USB2 drive does indeed do 30MB/s on a…USB3 port and only 25MB/s on usb2 port. So USB2 is even more limited then I remembered. This is with very good USB2 intel port.
Cheers Louis, thanks for the great work/support!
I have just had this issue, an immensely frustrating bug! It has nothing to do with the disk at all. Ive never had it before, but it just occurred this evening on a project that had previously been working fine. Only recorded it three weeks ago, no hardware/software changes whatsoever since then. Also, only (currently) affecting this project. Posting here in case this helps anyone:
So, this issue occurs if the play cursor is in the final bar of a cycle range. However, if you move the right marker off the bar boundary (say, 1/32nd or even if just a tiny amount not snapped) the issue completely disappears and it cycles just fine (though obs not on the beat as you would want it!). For me, in this project, it is happening at bar 17. But stranger still, if I insert silence at the beginning of the project it moves forward to match.
So I isolated it to one audio track. Nothing special about it, no variaudio, audiowarp or anything.
This might be useful to others, I’ve found a workaround:
Split the audio track at the start of the problematic bar (i.e. at the start of the bar before the cycle end marker). Moving the problematic split bar to a new lane does not help, but moving it to a fresh audio track fixes the issue.