I have a problem that I am tearing my hair out trying to fix. I have a 3.2GHz Pentium 4 laptop with 1GB of RAM, an 80GB 7200rpm Fujitsu hard drive, Cubase SX 2.2 and an M-Audio Firewire 410 interface for live use. The basic arrangement is a few synths, Kontakt and some effects. I then have everything I'm not able to play live running as audio files. I trigger the samples and play the synths with a Roland MIDI controller keyboard and use a Behringer BCR2000 MIDI controller to control levels, EQ and so on. All the audio files are 24-bit and there's about 120 of them. The Cubase song is about 45 minutes long, but each audio file is generally no longer than about 5 minutes.
What happens is that I'll be happily playing a track and the CPU is rumbling along at about 30 percent then suddenly, often seemingly as a direct result of MIDI input, it jumps up to 100 percent, cuts out the audio for a second and then returns to normal. Now I have tried absolutely everything to fix this, but the problem is still there. I am now wondering whether I should re-render all these audio files in 16-bit. Do you suppose this may be the culprit? Any help would be really gratefully received, as I have a really important gig coming up and am desperate to get it fixed before then.
SOS Forum Post
PC music specialist Martin Walker replies: You've got a capable hard drive there, so I doubt that it's the cause of the occasional glitch. However, although you say you have around 120 24-bit audio files to play back during this song, you don't tell us the sample rate or maximum number of files playing back simultaneously. This is more important, since it determines the data transfer rate required — running at a sample rate of 96kHz will double the requirements compared with 48kHz.
A typical internal 7200rpm drive may be able to play back up to about 48 24-bit/96kHz tracks nowadays, although a laptop model may not manage quite so many. I carried out some measurements on various laptop, desktop, and external hard drives back in PC Notes April 2004 if you're interested in seeing some more figures. However, assuming you're running at 44.1kHz rather than 96kHz you ought to be able to manage 48 simultaneous 24-bit/44.1kHz tracks with ease on your setup.
So, somehow I doubt that the drive capabilities are letting you down. The cause is more likely to be a change in the middle of the song where it suddenly accesses a huge number of new files simultaneously. This would place a sudden demand on your drive that might push it over the edge. Make sure your drive is defragmented so its read/write heads are not being called on to jump about more than is necessary. However, reducing the bit-depth from 24-bit to 16-bit will instantly drop the load on your drive by 33 percent, so this is well worth doing for a live gig where the difference in audio quality is unlikely to be noticed.
Another tactic would be to mix down those tracks that no longer require individual tweaks during your live performance. If, for instance, you've got a maximum of 20 or 30 simultaneous tracks playing, but only want to drop up to half a dozen in or out or tweak their filter settings in real time as part of your performance alongside playing in live MIDI lines, mix all of the others down to a single stereo track. This will instantly drop your disk access requirements by a considerable amount, and at a live gig, reliability is more important than flexibility. Make a backup of the original multitrack version first, so you can always return to it back in the studio for more tweaks if necessary.
Also, make sure you have the very latest drivers installed for your M-Audio Firewire 410, and while you're checking this on M-Audio's web site, have a read of their helpful Knowledge Base (follow the Support link at www.maudio.co.uk) to see if anything rings any bells with your particular setup.
I spotted this item in particular: "M-Audio Testing has been investigating a matter where certain resource-intensive applications requiring a heavier disk access can cause the audio engine to suffer as a result. Whether using on-board audio or ASIO with M-Audio Firewire interfaces, the results were the same. If the CPU meter in the application peaked above 75 percent at any time, the computer would become unresponsive and audio would distort causing the application to become unstable.
"Please be advised that laptops most commonly have hard drives that are slower than desktop drives and are used as memory caches when there is not enough physical RAM to host the application's needs. A 7200rpm drive is recommended for multi-channel recording and playback."
Now in your case you already have a 7200rpm drive and a healthy 1GB of RAM, and your CPU mostly remains at 30 percent, but it does suddenly jump to 100 percent when the problem occurs, which ties in with this description. The sudden jump might be caused by a particular plug-in (read my PC Notes column from October 2002 for a description of the infamous P4 denormalisation problem, which can cause occasional CPU spikes — www.soundonsound.com/sos/oct02/articles/pcnotes1002.asp) and you can test this by temporarily moving the contents of your vstplugins folder somewhere safe and running the song again — if the glitching has gone, you can systematically move the plug-in files back while testing playback until the problem reappears. This may track down the culprit.
Tweaking your settings for Kontakt may also help, particularly since you can adjust the proportion of the sample data being buffered in RAM rather than streamed from the hard drive. You're already streaming lots of files for your audio tracks, so reducing the amount required for software sampler streaming will lessen the load on your drive — refer to Kontakt's manual for optimisation tips or just increase its RAM setting a little at a time and see if it helps.
If you're still having problems after these various suggestions, try massaging the song data slightly. Avoid hard quantising where huge numbers of MIDI, software synth or sampler notes start simultaneously — try moving the starts of some of them back in time slightly to spread the load on both your CPU and hard drive. As long as you avoid doing this with drum or bass parts, this is rarely audible if you're careful.
However, I suspect moving from 24-bit to 16-bit files and pre-mixing some of the tracks will cure your problem, as it will instantly drop your hard drive overheads by a huge amount. Good luck!