You know what you want your computer to be capable of. So how do you decide what combination of CPU, memory and hard drives will make this possible?
A common question among those buying or upgrading a PC is how to choose the right specification for a particular task. For example, let's say you need to work with Steinberg's CubaseSX, along with an ambitious clutch of soft synths and soft samplers such as Propellerhead's Reason 2, Spectrasonics' Atmosphere and Stylus, Steinberg's Absynth, Halion and TheGrand. You want to play back 30 or 40 audio tracks along with 20 or so MIDI ones, and then to add a generous sprinkling of plug-ins. Will, for example, a 2.4GHz Pentium 4 processor with 512MB of DDR SDRAM plus an 80GB 7200rpm EIDE hard drive do all this, or would you need a 3.0GHz processor, more RAM, faster SCSI drives, a RAID array, or even a helping hand from a DSP card such as TC's Powercore or Universal Audio's UAD1?
This sort of question is actually very difficult to answer, since it depends on how the PC been set up and what exact combination of audio and MIDI tracks, plug-ins, soft synths, and soft samplers you're using on each song. However, what we can look at more closely is how these resources are consumed by the different music applications, so you can make a more informed estimate of your requirements, either to upgrade your current PC or put together a spec for a new one.
Windows & Application Requirements
Compared with the vast majority of modern music applications, Windows' own system requirements pale into insignificance except in one area: the disk cache. A significant amount of your system RAM may be allocated to this, to store the most recently accessed data from your hard drives in case it's needed again, in which case there's a considerable time saving.
If you're still running Windows 98/Me, make sure you set up your disk cache using this well known addition to the System.ini file, but check that MinFileCache precedes MaxFileCache, otherwise both settings will be ignored.In Windows 98SE/Me you can set this vcache size by hand, and a sensible size for this is normally quoted as a quarter of your system RAM. In a 512MB system this would be 128MB, but you can drop this to 96MB or 64MB if you want more RAM for sample storage, without noticeable repercussions. I've written about the potential resizing problems with the Windows 98/Me vcache on many occasions, but as long as you set its maximum and minimum sizes to the same figure they won't happen. Note that you should always place the MinFileCache setting before the MaxFileCache setting inside the System.ini file. If you do it the other way round (the way Cubase VST has always done for instance) your new settings will be ignored. Cacheman (www.outertech.com) does it the correct way round, although you'll have to delete the incorrect version first if one exists.
Windows 2000 and XP have much better disk cache handling, and you don't need to adjust it manually, although Cacheman does offer various configuration presets to either minimise the memory used, or give higher priority to the disk cache, applications, or a balance to both. The first is probably the best setting for most musicians.
My Windows 98SE setup, with a fixed 64MB vcache, uses about 100MB in total by the time it reaches the desktop, as do my Windows XP partitions, running with a fairly typical 512MB of RAM, leaving plenty for other duties. Few music applications display how much memory they are currently consuming, but it's fairly easy to find out by using a suitable monitoring utility (see the box on the final page of this article for more details). Just read how much system RAM is being used before you launch it and again afterwards, and then calculate the difference. I tried a raft of PC music applications including Cool Edit Pro 2, Cubase VST 5.1 and SX, Gigastudio 160, Sonar 2, Sound Forge 6, and Wavelab 4, and nearly all took under 20MB for their own use, except for Cubase SX, which needed 55MB.
CPU Overhead And Latency
Every PC musician's goal is to achieve low latency, but once you drop below about 12ms, CPU overhead will start to rise, simply because of the frequency of interrupts, each consuming its own small amount of overhead. I carried out a few quick tests with my Echo Mia to demonstrate my point, and found that on a typical Cubase SX song CPU consumption was fairly constant down to about 12ms (512 samples at 44.1kHz), but with a 6ms setting it rose by about 10 percent, and at 3ms by a hefty 40 percent. Similarly, Sonar 2 rose by about 25 percent when I dropped its Effective Latency from 12ms to 6ms, by nearly 70 percent at 3ms, and 100 percent at the lowest 1.5ms.
Audio Tracks
The easiest performance issue to predict for any music PC is the likely number of simultaneous audio tracks you'll manage, since this is primarily determined by the rotational speed of the hard drive. Modern IDE drives are fast enough that most musicians won't need to tackle the added complications of SCSI or RAID.
A modern drive with a typical sustained transfer rate of around 40MB/second could theoretically manage hundreds of mono 44.1kHz, 16-bit tracks. However, in real life the various audio files will be spread around on the drive, requiring the read/write heads to dart about, slowing down this process considerably and therefore dropping the maximum possible number of simultaneous audio tracks.
Dskbench may only provide a basic text-only display, but the results it gets from your hard drive can be invaluable.One the easiest ways to check what your hard drive is actually capable of under approximate real-world conditions is still Jose Catena's Dskbench utility (www.sesa.es), which not only measures the sustained transfer rate for both reads and writes, but also the number of simultaneous 16-bit/44.1kHz tracks you can expect with different disk buffer sizes. As you can see from the screen shot, as you decrease disk buffer block size from 128kb the theoretical track count drops, because the read/write heads spend more and more time darting about between the various files. Exactly the same drop occurs with fragmented files, which is why you should keep your audio partition defragmented on a regular basis.
Although Dskbench only displays track counts for mono 16-bit/44.1kHz files, simple calculations can quickly convert these to other formats. At 48kHz, your track count will only drop by about 8 percent (44.1/48), while 24-bit playback requires a 50 percent increase in data throughput for each track, with a corresponding drop in track count of a third. Anyone using the Cubase 32-bit recording option will get half the number of 16-bit tracks, while those who indulge in 24-bit/96kHz operation will find track counts have plummeted by around 70 percent. Anyone recording at 24-bit/192kHz may need to increase block size to 256kb if their music application permits it, or investigate faster drives or a RAID array.
As long as you don't have such exceptional requirements, my advice is to stick with a single 7200rpm EIDE hard drive for audio purposes, which should be perfectly capable of running about 48 tracks of up to 24-bit/96kHz audio. If you're struggling to run more tracks then try increasing the disk block buffer size in your sequencer, since this won't consume much RAM in the grand scheme of things. On modern PCs, you may also have the option of using an external Firewire drive, either using a socket directly mounted on the motherboard, or via a cheap Firewire PCI card. These are handy for additional storage, although performance isn't generally as good as an internal IDE model.
Don't be tempted to run your projects at 96kHz unless you're prepared for a huge hike in processor overhead. Here's a composite screenshot showing what happens to the Cubase SX performance meter when changing from 44.1kHz (left meter) to 96kHz (right meter).
PC Plug-ins
Once you get to audio effect processing, it's primarily the speed of the processor that determines ultimate performance, and it's rare for plug-ins to require much RAM. However, one extremely important fact that still seems to bypass some PC musicians is that the processing requirements of any plug-in are directly proportional to sample rate. With some soundcards, changing to 96kHz can also halve the minimum latency value, but you should only do this if the lowest 44.1kHz latency you can manage is unusable and you've got a really fast processor.
In general, EQ, filter and dynamics plug-ins take comparatively little CPU power, although of course you may need to use many of them at the same time. The gluttons continue to be reverbs, but these are generally used as global auxiliary effects rather than channel inserts, so you shouldn't need to use more than one or two simultaneously.
The CPU consumption of any plug-in can be radically altered by CPU-specific coding tweaks, particularly for the Pentium 4 range, which can benefit hugely from SSE2 optimisation where it's available. For instance, when Waves updated their Renaissance Reverb to v3.5, its CPU overhead dropped by a factor of three on the Pentium 4. Plug-in CPU overhead can also rise unexpectedly due to the Pentium 4 denormal mode problem that I discussed in PC Notes October 2002. Although it also affects Intel's Pentium II, III, and Celeron ranges, as well as AMD's Athlon, it does so to a much smaller extent. Most developers have now tweaked their plug-in code to avoid the issue altogether, but you may find that a few older plug-ins cripple your PC.
Software Synths
You might think this soft synth part would only need four-note polyphony, but to avoid obvious note-robbing while one chord decays and another takes over actually needs eight notes, and therefore double the CPU.The CPU consumption of software synths is also proportional to the host application's sample rate, and usually to the number of simultaneous notes they're trying to play back. Where possible, most soft synth developers use 'dynamic voice allocation', which can make a huge difference to overall CPU consumption, by disabling each note once its contribution has died away to virtual silence. The most critical to set up are those soft synths that take a high processor overhead for each note, such as AAS's Lounge Lizard, which uses physical modelling — beware of using the sustain pedal with instruments such as these, since this can send polyphony rocketing. Some soft synths impose a constant CPU overhead set by whatever fixed maximum polyphony you choose, whether you play any notes or not. Examples of this type include NI's Reaktor and AAS's Tassman, the added complexity of modular designs meaning that they may not have a handy envelope generator in circuit, making it impossible to determine when each note has finished.
Soft synths that aren't based around sample playback, such as NI's Pro 53, tend to use very little memory, but sample-based synths such as Spectrasonics' Atmosphere and Trilogy, Edirol's Virtual Sound Canvas and IK's Sampletank are a different matter. Unless the entire sound set is small, most only load in the data for the chosen patch, and thankfully, those that do require a lot of RAM generally provide a readout of how much each one actually uses. Don't forget, though, that you may want to run multiple instances of memory-hungry soft synths.
Software Samplers
Software samplers are distinguished from sample-based soft synths by their ability to load in your choice of sounds, and are often the most demanding component of a music PC. This is because while CPU requirements per voice are modest compared to many soft synths, we tend to want higher polyphony, and to use them in multitimbral mode to load in lots of different sounds, which ramps up both RAM usage and CPU overhead.
If your soft sampler offers disk streaming this can shift resource consumption considerably. This imported Gigastudio instrument needed 175MB of system RAM to load, but activating the Kontakt 1.2 DFD (Direct From Disk) extension created a new Kontakt-format file set of 185MB, and then system RAM usage dropped by a similar amount, although of course there is more disk activity.Some soft synths rely entirely on loading samples into the computer's RAM, but Gigasampler and the more recent Gigastudio stream the sample data from the hard drive as required, allowing long samples to be used when looping might sound artificial. Despite this approach, Gigastudio still needs plenty of system RAM in many cases, which confuses of lot of people. The reason is that to achieve a low real-time latency, when you play a MIDI note it must already have the start of every note held in a RAM buffer, so that it can be clocked out while hard disk streaming of the rest of the note gets up to speed. Each sample only requires 64k, but the total amount used depends not only on the keyboard range of a particular instrument (and therefore the number of notes requiring buffering), but also the number of velocity levels and dimensions, and whether the samples are mono or stereo. As a guide, the average Akai import will need less than 15MB of your system RAM, while more complex instruments such as Gigapiano and Dan Dean's solo cello need 65MB and 70MB respectively. The hogs are those 'ultimate' libraries like Thomas Skarbye's 12-velocity layer Rhodes Stage Piano, which needs 253MB to run the full version.
Moreover, any soft sampler that streams audio from the hard drive also needs a drive with a fast seek time, since this will be a factor in determining how many simultaneous voices your PC can manage. Whereas playing back 48 tracks of audio mean that a drive's read/write heads will be jumping about attempting to fill up 48 sets of RAM buffers, running Gigastudio 160 flat out will require 160 or more sample buffers to be filled, depending on how many velocity levels and dimensions the library supports.
The other two main PC soft samplers are Halion and Kontakt. Both now allow you to decide how much of each sample is stored in system RAM, and how much disk streaming activity takes place, using exactly the same principles and constraints as Gigastudio. NI's Kontakt version 1.2 defaults to using 120k per voice for disk streaming, and with a fixed number of reserved voices that defaults to 32 this only takes 3.75MB, and even with 160 voices would only take 15MB. However, in practice this number of voices could bring your PC to its knees, as it also could with Halion, so more RAM is often required to increase polyphony.
Conclusions
Hopefully, if you know what you want to achieve with your music PC, this article should have helped you decide what specification is appropriate. If you want to do basic audio recording and only want to run some MIDI tracks and a few plug-ins alongside, even an old PC like a Pentium II 266MHz or equivalent machine running Windows 98SE with 128MB or so of RAM will cope. Once soft synths enter the picture, I think a realistic but basic spec for a music PC is a Pentium III 1GHz or equivalent processor with 512MB of RAM and an 80GB 7200rpm hard drive; 1GB RAM is more desirable for those who intend to buy any of the 'ultimate' acoustic instrument libraries.
Monitoring System Requirements
While some applications like Gigastudio display their own CPU and RAM consumption, you can still monitor your PC's total requirements using an external utility like Cacheman and System Monitor.
Don't forget that if you're running multiple applications then each one is likely to display only its own consumption — if both Gigastudio and Cubase display 45 percent then your PC is tottering on the brink of CPU overload. One way to monitor the current totals in such cases is to use a separate CPU meter, such as Microsoft's System Monitor, which can also display how much of your physical memory is still free. Windows 98/Me users should already find a shortcut to this in their Accessories/System Tools menu, while Windows 2000/XP users should follow the Administrative Tools icon in Control Panel, and then click on Performance.
Other third-party utilities are also available, but my favourite on the memory front is still Cacheman, which displays both physical and virtual memory usage in a very easy to read bar-chart format as a percentage of the total available in your PC, and only has a shareware registration fee of only $10. By the way, if you're running short on RAM, don't be tempted to run Cacheman's Recover Memory feature or those of similar utilities, since these tend to work by swapping out any unused items to the swap (page) file. While this may seemingly give you more RAM, it could also increase the likelihood of later page file activity. When I tried it while running Cubase SX and Gigastudio 160, Cacheman managed to claw back a tiny amount of RAM, but the first time I played back the song I was working on it glitched badly when each instance of Atmosphere tried to play its first note.