XO Wave: Hardware Settings

The Hardware Settings window controls how the session uses audio hardware. For example, you can select the devices to use for input and output (if more than one suitable audio device is available for either), as well as latency and dither settings.

For more info on latency and other performance issues, see our guide to Optimizing Mac OS X Performance for Audio and Video Users.

The dither settings are described in more detail in A Bit about Dither. If you are producing podcasts, CDs, or other 16-bit output, you should not need to change this setting.

On the right side of the window are several latency-related controls. Latency is the delay caused by audio buffering. In general, latency controls the trade-off between overall responsiveness and likelihood of buffer underruns. Buffer underruns occur when XO Wave (or one of its components) cannot produce or consume data at the rate that the sound hardware requires (technically, not consuming data quickly enough usually results in a buffer overrun, but for simplicity, XO Wave refers to both conditions as underruns). The result of an underrun depends on your system and your settings, but either playback will stop and you will be told that there was an underrun, or the output will stutter.

The first control under Latency Settings is the Number of Preload Buffers, which controls the number of buffers to read off disk before beginning playback. Setting this too low can cause buffer underruns, while setting it too high can waste large amounts of memory and make editing (particularly cutting and pasting regions) lag behind the latest changes to your session. With more preloading, playback will be less likely to underrun, but too many buffers can prevent playback from reflecting the latest changes to the project.

The next control, Number of Playback Buffers, is usually ignored on Mac OS X because Apple's Core Audio is designed to always use two buffers. As a rule, it is only used with separate input and output devices, in which case this setting provides a hint as to how much latency is desired between the two devices. When using separate devices for input and output, differences in clock speed and native block size make buffer underruns much more likely than with a single device. Setting a higher number of playback buffers will increase the latency of the devices, making underruns much less likely. On other systems, this controls the number of buffers which are processed before playback. Setting this high may cause slow response to things like fader or effect changes. Setting it too low may cause underruns.

Samples Per Buffer controls the size of the buffers and has a multiplicative effect on both the Number of Playback Buffers and Number of Preload Buffers. It is a good idea to match samples per buffer to the comparable parameter on your sound hardware if at all possible. Many high-end sound cards specify the samples per buffer in their documentation, and some even let you adjust their natural buffer sizes. Note that some audio systems, such as ALSA on Linux, do not work properly unless this parameter is within a certain range. This is normally not an issue on Mac OS X.

Total Software Latency is an estimate, based on your settings, of the maximum total latency in milliseconds introduced by XO Wave. Generally speaking, the lower this number is, the more "responsive" XO Wave will be to effect changes, and the less delay there will be when playing audio through XO Wave, such as when recording. Latency may be higher due to your hardware, or lower because XO Wave is able to keep some of the buffers empty. If latency is too low, you may experience playback or recording drop-outs, as well as excessive CPU usage or other performance problems.

Record Delay allows you to automatically offset recordings to correct for any delay caused by your sound hardware. For example, if you record a segment of audio and it is delayed on playback, you can use this to compensate: just enter the number of samples the signal is delayed and XO Wave will automatically adjust to compensate.

Allow Underruns causes XO Wave to continue playing back even if it detects buffer underruns, rather than stopping (XO Wave's default behavior). Note that this is just a hint to the system -- not all platforms support proper detection of underruns.