On any personal computer system, there is a delay between the moment you input a sound, or “tell” the hardware to play a sound, and when you actually hear it. This delay is referred to as the “latency” of the design. This imposes a problem for any system where you want real-time user input to affect the sound.
All audio applications receive and generate their audio in chunks. These chunks are then passed on to the audio card where they are temporarily stored before being converted into regular audio signals. The storage place for these chunks are called “buffers” (an analogy would be a bucket brigade, where a number of people each have a bucket, and water is poured from one bucket to another to reach its final destination).
The smaller the buffers and the fewer they are, the more responsive the system will be (lower latency). The general rules regarding the buffer size are these:
|
•
|
A small buffer size reduces the latency (the time it takes for the audio to “travel” from the audio interface input(s) to the application and from the application to the audio interface output(s)).
|
However, a small buffer size also increases the DSP Load. Too small a buffer size setting could also make the sound crackle and distort.
|
•
|
A large buffer size reduces the DSP Load (allowing for more tracks to be played back simultaneously) and also ensures good audio quality.
|
A high sample rate will also reduce the latency. However, this will also raise the demands on the computer and its software. If the system can’t cope with moving the data to and from the buffers fast enough, there will be problems that manifest themselves as glitches in audio playback.
To make things worse, audio playback is always competing with other activities on your computer. For example, a buffer size that works perfectly under normal circumstances might be too small when you try to open files during playback, switch over to another program while Reason Essentials is playing or simply play back a very demanding song.
On a regular PC, the latency can vary quite a lot. This is an effect of the fact that computers and their operating systems were created for many purposes, not just for recording and playing back audio. For multimedia and games, a latency of a 100 ms might be perfectly acceptable, but for recording and playing back audio it is definitely not!
|
•
|
A card specifically designed for low latency, with an ASIO driver under Windows, or a Core Audio driver under Mac OS X, can usually give you figures as low as 2-3 ms. This is definitely good enough for audio applications. That’s also why ASIO or Core Audio drivers are required to run Reason Essentials.
|
When Reason Essentials’s sequencer is playing back a song, the timing between notes and audio is perfect! Once playback of a Reason Essentials pattern or song is up and running, latency isn’t a consideration at all. The computer clocks the audio between the steps and does this with perfect quartz accuracy! The timing is immaculate!
When you run Reason Essentials as a ReWire slave, it is the other program, the ReWire master, that is responsible for actually rendering the audio and playing it back via the audio card. It means that any latency is present in the ReWire master.
|
When Reason Essentials runs as a ReWire slave, what audio hardware you have, what audio driver you use, and the audio settings you have made in the Preferences dialog are of no importance at all! All audio hardware settings are then instead made in the ReWire host application.
|
|
|
Note, however, that you may have to adjust the “External Sync Offset” in Preferences if Reason Essentials is synced via MIDI from the host application (see “Synchronization considerations”).
|
You might run into situations where you have to raise the Output Latency setting to be able to play back a very demanding song on your computer. Another option would be to actually optimize the song. See “Optimizing Performance” for details.
This is only required if you find that you need to increase Output Latency because your audio card can’t really cope with the songs you try to play.
This is only required if you find that you need to increase Output Latency because your computer can’t really cope with the songs you try to play.
When you run Reason Essentials, the clock speed of the processor is a major factor determining how many audio tracks and devices you can use at the same time.
If you plan to buy a computer specifically for Reason Essentials, you could play it safe and choose a computer with at least a dual-core Intel P4, or equivalent AMD processor, running at 2.0 GHz or faster. MultiCore processors will give better performance and are highly recommended.
Another important performance factor is the amount of installed RAM in the computer. Generally, one could say: the more the better, especially if you’re running several applications simultaneously. To run Reason Essentials, a minimum of 4GB RAM is required, but more is recommended for even better performance.