Optimizing your system for audio recording

In the old days, I used to do CD quality recordings on my 386 system, featuring a 40 MHz CPU and a whopping 8MB of RAM. This system had only a fraction of the capabilities of your current machine. Still, it did not have any problem at all keeping up with the data transfers, and the recording time would be limited by the size of the harddisk only.

Now in spite of the fact that we have 32-bit operating systems, and many enhancements, systems still appear to be incapable of doing a decent recording of audio. The only performance requirement that your system must be able to meet is the ability to continuously transfer about 175kB of data to the harddisk. Taking into account that new harddisks have been performing far above these requirements with megabytes per seconds, that should not pose a problem. Still, when recording data, you can hear clicks and pieces missing because the system failed to meet the 175kB/s requirement.

VCACHE: The most likely cause

The first thing to tune is the virtual cache of Windows 95 (or 98). If you are running an NT based system, like Windows NT or Windows 2000, this section will not apply to you.

Windows 95 features a caching mechanism, that speeds up harddisk access by keeping frequently accessed data in RAM memory, and by delaying writes to the disk. The implementation in windows 95 has a serious design flaw, that interferes with audio recording.

The problem

Harddisks perform best if you feed them large chunks of data in bursts. They don't like writing tiny pieces of data scattered all over, and will noisily protest against such abuse. So the cache system kicks in and helps you out. At least, it does when you are doing some word processing or something like that. What the cache does is accumulate data and send it out to the harddisk in chunks. It also keeps the most recently written data in memory. The memory that it may use for this purpose is all the available memory that hasn't been claimed yet.

But something goes wrong with this scheme on 95 systems. If you are writing a single, large file, like an audio recording, the system will keep all that data in memory. When all available memory has been used, the cache system will still attempt to use more memory. The memory mangement then looks for parts of memory that haven't been used for a while, and throws these out, moving them to your disk if needed. The memory occupied by the cache has all been most recently written to, so the regions that it discards are most likely you program's code and the background image and such. The disk will become noisy as more and more of your programs and data are being moved out to the harddisk to make room for the cache. Eventually, your system will become slower and slower, because of the lack of memory, and the harddisk will get busier and busier, until eventually, your system is incapable to keep the audio recording going smoothly. This is causing the clicks.

The solution

The solution is very simple. Limit the memory hungry file cache, and instruct it to use no more than a fixed amount of memory. This will prevent the cache from eating all your memory, as it will not attempt to allocate more memory after it used up the limit.

  • Open the file SYSTEM.INI, most likely located in the directory C:\WINDOWS. If you just double-click the file from Explorer, it will open in Notepad for editing.
  • Search for the section in the file that is labeled [vcache].
  • Below this header, enter the limits you wish to impose. The rule-of-thumb is to set the minimum size to about one megabyte (1024kB) and the upper limit to about a quarter of your system's RAM (for example, if you have 32 MB of RAM, you would allocate 8MB (8192kB) to the file cache.
  • The entry in SYSTEM.INI should now look like this:



    You must supply a MinFileCache size, otherwise the MaxFileCache will be ignored. After making these changes, save the file and restart the system to make them take effect

    Sometimes there is a "chunksize" setting as well. Suggestion is to leave it at the default of 512 bytes. Here is a site with pages of information on that topic.