Other Considerations
Many things will effect the performance of digital audio software in general, and multi-track production software in particular. The performance of the disk drive being used to store the audio data is only the beginning. Naturally, this component must be of optimum efficiency in order to allow real time streaming at a high track count. However, this isn't necessarily always going to be the limiting factor in a DAW's performance. There are other places to look as well.

Having a modem plugged into a DAW's PCI bus can lead to conflicts, particularly if the modem is a voice modem. Some production software will attempt to configure the modem as a sound card. While more "aware" programs such as Cakewalk will report a modem upon finding it and allow you to ignore it as part of the sound system port setup, other programs may not, and could default to a lower bit depth or sample rate as a result. Many DAWers agree that an external modem connected to one of the computer's serial ports is the safest way to go here.

Likewise, using a fancy accelerated 3D "gamer's" style video card can cause significant degradation in system performance due to the high demands of the card on system timing. The fact is that DAW software is not graphic intensive and doesn't require a high performance video card unless you intend to do A/V production. If that is the case, follow the recommendations of others in the field who are using the same kind of mother board/processor configuration as yourself and choose a video card accordingly. Sometimes turning down the hardware acceleration slider (from Control Panel double click the "Display" icon, go to the "Settings" tab and click the "Advanced" button. The slider is in the "Performance" tab) will improve performance, though it can also disable your video card's higher resolution/color functions.

You may want to consider maintaining your DAW separate from all non-DAW operations and use another computer for internet activity, game playing and business applications. Your DAW might then contain only the sound cards, video card and an Ethernet card to allow transfers to and from the DAW and the separate system containing the CD recorder, internet access, back-up space, etc. You may consider not even  putting a CD drive in the DAW. You can access the CD ROM on the other system over the Ethernet as effectively as if it were a local drive. To prevent the Ethernet LAN from consuming system time, you can re-boot your system when you wish to do very demanding streaming production and at that time decline (hit ESCAPE) when asked for your network password. When your production load is not so demanding or when you want to move files around, re-boot and enter your network password to sign on to the LAN. All of this may seem a bit extreme, but it doesn't hurt to consider it.

If you wish to use one system for all of your computing needs as well as a DAW, then you will want to consider carefully each choice you make in terms of devices and software you install. After any changes you make, test your system fully for potential conflict with your sound equipment and production software. This way, if something causes trouble, you can quickly pin it down to a single item.

As a general rule, do not load or configure any screen savers or activate the power saver functions of your DAW. These features consume resources and at the oddest moments. Screen savers were important in the days of monochrome displays due to screen burn-in. However, modern color monitors are not subject to this problem, so don't bother with them. Do not use a background virus scanner, although you will want to have one loaded to perform scans on demand from time to time.

There has been some debate as to the proper allocation of disk space in a DAW. For one thing, many feel it is important to keep the software and data on separate drives for fear that the system might bog down if required to access different parts of the same drive for software while data is streaming. Indeed, according to Ron Kuper, Chief Technology Officer at Cakewalk, "When you have a large executable plus DLLs, (simply) running the program doesn't always ensure that all of the bytes (for that program) are loaded into physical memory. Some "pages" of the code can remain on disk, and will be paged in on demand when certain areas of the program are executed for the first time. For an example of this, watch what your disk does the first time you open the Staff View in Cakewalk. Then watch it again the second time you open the Staff View. Also, every program has "resources" (text, menus, dialog boxes, etc) which live on disk, paged in on demand. So unless the DAW prevents the user from manipulating the UI during playback, it is not true in general that the only disk access you'll get during streaming is from the data files. Of course, there are ways to be clever and force things to get paged in ahead of time. This is actually easier to do under NT than on Win9x, but on a system with not a whole lot of RAM this isn't a good idea."

The key word in the above statement is "RAM". If a DAW has sufficient RAM, then the user can open the views they intend to use during streaming before streaming starts. Those resources are then pre-loaded into memory. As for the dialogs and menus and so on, it must be understood that cranking around in the program while doing very demanding streaming isn't a very good idea anyway, even if the disk access for those resources is negligible. The simple fact is, once a digital production program is running and streaming data, the drive shouldn't have to access the disk for more software. All the software it needs should be in RAM. With a bit of planning and prudent use of the UI during streaming, this shouldn't become an issue. Therefore, there is no drive access conflict. Aside from being able to back up one drive to the other to guard against loosing your data to a sudden disk crash, the best reason to use 2 drives isn't to keep the data and software separate, but being able to put the partition holding your streaming data at the very front of a drive. This has advantages as we will discuss below, and has a much higher impact on overall performance than having the data and the software on two separate drives.

Mr. Kuper also offers the following observation, "Another process which can hit the disk unexpectedly is virtual memory compaction and/or cache cleanup. Windows can decide to do this during 'idle' time. What constitutes 'idle' time? It's up to the O/S."

With the virtual memory wild card in mind, many have advocated that disabling the Windows virtual memory will provide a boost in performance because the system will no longer attempt to use the swap file on the disk, removing this possible conflict during streaming. This is not a good idea. Again, if you have the proper amount of RAM in your system to load the software you need and to buffer the data as it streams, then virtual memory will not need to swap at all. Guarding against errant housekeeping tasks is almost impossible, however, you can minimize the effects. For advice on optimizing the virtual memory system, read the article Virtual Memory Optimization by José Catena available from www.ProRec.com. There is also good advice there on how to change your Windows cache settings to enhance performance. This article is required reading for anyone wishing to fine tune their system.

Another simple tweak that helps is setting the "System Type" and "Read Ahead" optimizations. To get to them, open Control Panel and from there double click on the "System" icon. Go to the "Performance" tab and then click on the "File System" button. There is a box that allows you to select the use to which your PC will be put. The "Desktop" setting is the default and will likely be the setting you see when you look here. Changing that to "Server" gives higher priority to disk I/O, which usually helps a bit with disk intensive applications such as those found on a DAW.

You will also see a "Read Ahead" optimization slider. By default, this should be set to maximum (64 KB) We recommend that you leave it there. It might be worth noting that some audio programs recommend resetting it or even set it automatically to the minimum, but this usually results in very little improvement for those programs and noticeable degradation for others. It might be wise to check this setting from time to time to see if it has been tampered with, especially if you notice a sudden drop in performance of your system after running a new program for the first time.

Some drive optimization tricks can make a big difference. One is to partition the drive such that your audio data is concentrated at the front of the disk. This area has as much as 60% faster access performance than the back of the disk. On a single drive system, one might partition (for example) a 10 gig drive with 10 MB as a C drive boot partition only, which then points to the E drive where the operating system is installed, then a D drive partition of 6 gig for audio. The back partition, the E drive, would hold Windows itself and the application software. It is also true that streaming is more efficient using large cluster sizes, not the default 4K clusters generated by the Windows FAT 32 partitioning system. You can force the issue by applying the /Z:64 switch to the FORMAT command. This switch will tell FORMAT to build each cluster out of 64 sectors thus generating 32K clusters (each sector is 512 bytes). Better still, use a program like Partition Magic to reset the cluster sizes without having to reformat the drive or destroy your current data. As a side note, if the partition in question is 2 gigabytes or smaller in size, it can be partitioned using FAT 16 instead of FAT 32.

Certain multitasking schedule and synchronization issues can degrade file I/O performance because audio buffer processing is a very high priority task. It can take a significant amount of available time, particularly with heavy real time effects loads. This can be minimized if disk I/O is done through bus mastering or at least DMA, and the application has been designed to optimize disk I/O throughput. As a general rule, the ratio between audio buffer size and file buffer size is critical for such optimizing. The larger the file I/O buffer, the better. The smaller the audio buffer, the better. The file I/O buffer size should be large enough so that the typical time required to transfer a file buffer to/from disk is significantly larger (4 times or more) than the time required to playback an audio buffer. If the time ratio is low, the performance penalty will be large, and if it's below 1, it will be dramatic. As a consumer, it is up to you to judge your application software wisely and invest in an application that has a good track record overall, and a commitment to customer support. If the software can't take advantage of the high disk throughput you've invested so much into, then you've shot yourself in the foot.

Go to Page 3 (Part 2); Back to TOC