I will try to dig into this a bit. Warning this is long, so if you
get bored easily.....

Latency can be defined in different ways based on the context in
which you are discussing it. I will attempt to define how we look at
it.

Latency during playback:

The time between moving faders, fx parameters, or any mixing actions
and hearing the change is the playback latency.

All audio hardware that are using Wave API based drivers involve a
latency during playback. When you stream audio to the hardware you
have to buffer some audio to the hardware while the application is
building the next buffers to be queued. Once you hand over a buffer
of audio data to the hardware, you can't touch it. The goal is to
make the size of these buffers as small as possible so that 1) the
hardware has enough to play while the app is preparing the next
buffer to be queued and 2) queue the next buffer in time so that the
audio hardware has new data available when the previous buffer
completes. If this doesn't happen, you hear gaps in audio.

The smaller the buffers, the more "realtime" faders and fx changes
feel and hear. Larger buffers make mixing actions feel sluggish and
unresponsive.

By default Vegas has a latency buffer of .25 secs. This buffer is
actually split in two, so the actually hardware latency is half this.
This setting provides reasonable realtime response to moving faders
and hearing the changes. The buffering can be varied from 10 msec to
2 secs.

There are other factors that can introduce a larger latency during
playback. The best example is the use of Acoustic Mirror as and
assignable FX or Bus FX. Mirror will introduce a latency equal to the
impulse file being used. If the impluse file is 3 seconds, the this
becomes the overall latency of any source routed through Mirror. Why?
In order for Mirror to do its magic, it needs at least as much audio
as its impulse file to process before it produces any output.


Monitoring input Latency:
The time it takes to hear what is being recorded in realtime.

First, Vegas does not permit this. Why? Because we believe any
latency that would introduced would be unacceptable.

To record audio you must supply a buffer to the hardware, which the
hardware fills in realtime. By the time the hardware/driver returns
the buffer to the application, the time it was captures has passed.
If you want to take this input and immediataly stream it back out,
you have to buffer it again to the hardware which will add more
latency. What you hear is the audio playing behind realtime.
Unacceptable.

We let the hardware perform monitoring. The problem with this is no
realtime fx on input. It is a limitation, but a limitation that we
have to live with as the alternate solution is usless in our opinion.

(Before someone jumps on me...)
Yes ASIO permits a lower latency, but there is no such thing as zero
latency. I have seen claims of 10 ms and even 5 ms latency with ASIO
drivers. ASIO does permit the control of hardware monitoring. This is
not the same thing. It has the same limitations as telling the
hardware through its control applet to perform monitoring.

Recording offset latency:

When doing Simultaneous Record Playback, the new recorded tracks are
not aligned in time with the existing tacks. The new tracks are
offset late in time (It is rare that the new audio is early, but it
can happen.)

Most hardware will introduce some latency when recording and playing
back in realtime. This minimum latency is introduced by A/D
conversions and can vary from 1-5 ms. What this appears as after
recording is that the exiting tracks and new tracks are not lined up
perfectly by this offset. In general the A/D latency is acceptable to
most and is just part of the DAW world. Some will not tolerate event
the A/D latencies.

Some applications permit the user to compensate for this. Vegas 1.0
does not. Vegas 2.0 does. More on this below.

The MOTU 2408 specific problem is introduced by the hardware/driver
implemention and is based on the hardware buffer settings. The
latency introduced could be as much as 400 ms depending on the
hardware buffer settings. Terrible! The Vegas 1.0 solution was to
manually shift the new events back in time to line up with the
existing tracks.

There is another solution that MOTU implemented to solve the problem
for Cakewalk Audio Pro users. It involves a setting in a motu
specific ini type file. This fix basically tells the driver to drop
samples inorder to match output position to input. It works in
general, but it forces one to set the record start point a little
farther back than the actual point desired.

In our opinion MOTU implemented this incorrectly. In their opinion
we - and others - did it wrong. So be it. Since we realized that
MOTU was not going to address the problem, we have added a fix for
Vegas that will appear in Vegas Video and Vegas Audio 2.0. It fixes
not only the MOTU 2408 problem but permits the user to deal with even
the A/D offset problem if desired. It is very flexible.

Peter