What I've been looking at might be obvious to a lot of you, but it was
interesting to me. Without using any plugins at all and no aux/bus
channels, etc., there seems to be an approximate 1.94ms delay (93 samples @
24 bit 48kHz) every time a new audio track is recorded next to pre-existing
tracks.

This seems to be almost entirely independent of the Playback Engine's
Samples and DAE Buffer Levels. I experimented with the following settings:

512 Samples, DAE Buffer Level 2
128 Samples, DAE Buffer Level 2
128 Samples, DAE Buffer Level 4
1024 Samples, DAE Buffer Level 4
64 Samples, DAE Buffer Level 0

None of them seemed to affect my results except in the last case where it
brought the delay down to about 91 samples instead of 93.


This was tested with ProTools LE 6.2.3 running on a dual processor G5 w/ 2mb
RAM.

I started with a short 4 second file inside a new, empty 24bit, 48kHz
session. I created 6 empty mono tracks, and slided the file into the start
of track 1. I then played it to output 1, which was plugged directly into
input 5 on the 002R, recording that directly into track 2. I muted tracks
appropriately to avoid feedback and moved on down the list, 1 at a time, so
after the first pass of recording to track 2, I then used track 2's output
with its newly created file to record it into track 3, and so on down. Each
time there's a 93-94 sample delay, so after 5 passes, it adds up to almost
10ms.

In the real world, these subsequent passes would obviously be overdubs like
vocals, guitars, etc., and you would presumably be monitoring with a roughly
stable mix while doing overdubs (rather than the explicit/cumulative example
I set up), so the problem might not be so pronounced. Still, it seems to me
that this could cause a smearing of audio tracks, especially in mixes
involving a lot of overdubs, or at least certain type of overdubs more
susceptible to problems caused by short delays, like percussion hits...

Am I crazy? This has nothing to do with the "monitoring latency" that
people are always talking about - which has its workarounds. This has a
workaround too, if you're willing to go shifting new tracks back by 93
samples every time you record additional audio!

Why doesn't DigiDesign program some sort of offsetting fix into their
software?

Why doesn't anyone talk about this problem? Am I just missing something
here?

In article writes:

Am I crazy? This has nothing to do with the "monitoring latency" that
people are always talking about - which has its workarounds. This has a
workaround too, if you're willing to go shifting new tracks back by 93
samples every time you record additional audio!

It has to do with the time it requires to do an analog-to-digital
conversion and a digital-to-analog conversion. There's no getting
around that. But in practice you don't have to shift tracks by 93
samples when doing overdubs because your own timing isn't that
accurate. You really only see this behavior if you look for it by
performing the lab-type experiment that you did.

Why doesn't anyone talk about this problem? Am I just missing something
here?

Because it isn't a real problem.

--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

The 2 ms delay inherent in Pro Tools systems (it's the same on a TDM Mix system
too) is a well known fact. It's not normally a significant concern, but if
multiple successive A/D/A passes are done as you describe (which would be a
rarity) it would become quite audible. More commonly problematic is sending a
signal out to an analog processor and recombining it with the original sound
back in PT. Then, even a mere 2 ms delay will cause very noticeable
comb-filtering effects. The only way around it is to use a copy of the source
track to send out, and slide it earlier by the 2 ms beforehand.

Converter latency is a major issue in almost any digital sytem when A/D/A
conversions are involved. Some more than others. It was evidently one of the
main reasons for the early demise of the $$L Axiom digital console...


Ted Spencer, NYC

"No amount of classical training will ever teach you what's so cool about
"Tighten Up" by Archie Bell And The Drells" -author unknown

"Listendave" wrote in message
. ..

Why doesn't anyone talk about this problem? Am I just missing something
here?

I can only say that latency will never be zero, no matter how much we want
it to be.
1 ms is extremely good, 2 is still good. It will never be zero...

"Tommi" writes:
Why doesn't anyone talk about this problem? Am I just missing something
here?

I can only say that latency will never be zero, no matter how much
we want it to be. 1 ms is extremely good, 2 is still good. It will
never be zero...

I don't see why it has to be anything like 1 ms. A sample or two (.02
ms), maybe. But 93 samples? No really compelling reason.

Paul Rubin wrote:
"Tommi" writes:
Why doesn't anyone talk about this problem? Am I just missing
something here?

I can only say that latency will never be zero, no matter how much
we want it to be. 1 ms is extremely good, 2 is still good. It will
never be zero...

I don't see why it has to be anything like 1 ms. A sample or two (.02
ms), maybe. But 93 samples? No really compelling reason.

Sure there is.
This page has a picture of the block diagram of a really simple example of a
common kind of digital filter:

http://easyweb.easynet.co.uk/~nbarnes/

The little boxes with Z in them are 1-clock-step length delays. As you can
see, this filter has an inherent delay of 3 clocks. It's also a very simple
filter compared to what you might find in a modern digital audio system.
More complex = more delay steps.

The latency is mostly due to the delays that are required to produce digital
filters with the desired well-controlled amplitude and phase
characteristics.

In article writes:

Paul Rubin wrote:
I don't see why it has to be anything like 1 ms. A sample or two (.02
ms), maybe. But 93 samples? No really compelling reason.

Sure there is.

Remember, you're replying to "Mr. There's-No-Reason-Why-They-Can't-
build-what-I-want" here.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

Ok, but if these required delays are consistent, why not have the DAW
software compensate automatically when recording through the converters? If
I can do it myself manually...


"Arny Krueger" wrote in message
...
Paul Rubin wrote:
"Tommi" writes:

I don't see why it has to be anything like 1 ms. A sample or two (.02
ms), maybe. But 93 samples? No really compelling reason.

Sure there is.
This page has a picture of the block diagram of a really simple example of
a
common kind of digital filter:

http://easyweb.easynet.co.uk/~nbarnes/

The little boxes with Z in them are 1-clock-step length delays. As you
can
see, this filter has an inherent delay of 3 clocks. It's also a very
simple
filter compared to what you might find in a modern digital audio system.
More complex = more delay steps.

The latency is mostly due to the delays that are required to produce
digital
filters with the desired well-controlled amplitude and phase
characteristics.

Paul Rubin wrote:

I don't see why it has to be anything like 1 ms. A sample or two (.02
ms), maybe. But 93 samples? No really compelling reason.

Do you design digital gear and write code for a living? How much delay
is there between I and O on your digital gear creations?

--
ha

On Thu, 01 Apr 2004 16:44:13 GMT, "Listendave"
wrote:

Ok, but if these required delays are consistent, why not have the DAW
software compensate automatically when recording through the converters? If
I can do it myself manually...

That'll be in next year's FTL version.

Chris Hornbeck

On Thu, 01 Apr 2004 18:28:28 +0000, Chris Hornbeck wrote:

On Thu, 01 Apr 2004 16:44:13 GMT, "Listendave"
wrote:

Ok, but if these required delays are consistent, why not have the DAW
software compensate automatically when recording through the converters? If
I can do it myself manually...

That'll be in next year's FTL version.

Of course it cannot compensate during live monitoring, but I also see no
reason why the A/D latency cannot be compensated for on playback. I've
never found it a problem my self though. It would be cool to be able to
use outboard compressors without phasing problems when you record them
back in however.

I guess they don't do it because the computer would have to know which of
it's inputs were using A/D convertors, and which were digital ins.
Compensating then all equally would mean that digital imputs would creep
forward by comparison. Other non digi convertors may have
slightly different latency too... It's going to be pretty tiny in any case.



Chris Hornbeck

In article m writes:

Ok, but if these required delays are consistent, why not have the DAW
software compensate automatically when recording through the converters? If
I can do it myself manually...

They aren't necessarily consistent. They might be consistent for a
single path, but if you decide to use an outboard A/D converter,
that's a different delay. Many plug-ins (which often have substantial
and musically significant delays) can tell the program how much to
compensate when they're inserted, but that's something the program
knows about.


--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

In article ,
Listendave wrote:
Ok, but if these required delays are consistent, why not have the DAW
software compensate automatically when recording through the converters? If
I can do it myself manually...

All converters do not have the same delay.


Regards,

Monte McGuire

Monte P McGuire wrote:
In article ,
Listendave wrote:
Ok, but if these required delays are consistent, why not have the DAW
software compensate automatically when recording through the converters? If
I can do it myself manually...

All converters do not have the same delay.

That's why the software needs to be adjustable.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Scott Dorsey wrote:
Monte P McGuire wrote:
In article ,
Listendave wrote:
Ok, but if these required delays are consistent, why not have the
DAW software compensate automatically when recording through the
converters? If I can do it myself manually...

All converters do not have the same delay.

That's why the software needs to be adjustable.

I don't know about other multitracking software, but Audition allows tracks
and portions of tracks to be adjusted by any practical amount, and to within
one millisecond. I've this feature to adjust for acoustical time delays
among microphones, for example.

Arny Krueger wrote:

Scott Dorsey wrote:

Monte P McGuire wrote:

In article ,
Listendave wrote:

Ok, but if these required delays are consistent, why not have the
DAW software compensate automatically when recording through the
converters? If I can do it myself manually...

All converters do not have the same delay.

That's why the software needs to be adjustable.


I don't know about other multitracking software, but Audition allows tracks
and portions of tracks to be adjusted by any practical amount, and to within
one millisecond. I've this feature to adjust for acoustical time delays
among microphones, for example.

DP also, as well as Tascam DA-78HR. Both to within one sample. And there's a
plugin called Buffy (IIRC) and a few others that do that too.

"Listendave"

Ok, but if these required delays are consistent, why not have the DAW
software compensate automatically when recording through the converters? If
I can do it myself manually...

You mean like Nuendo? g 2ms is pretty good though, it's just that it's
so distracting from the music to be worrying about the numbers. Best thing is
I think have a procedure for how to deal with it and do it until it's automatic
and you don't have to think about it anymore.

Will Miho
NY Music & TV Audio Guy
Off the Morning Show! & sleepin' In... / Fox News
"The large print giveth and the small print taketh away..." Tom Waits

In article writes:

All converters do not have the same delay.

That's why the software needs to be adjustable.

Not only that, but it has to be able to inquire what converter is
hooked up, and know its throughput delay. Damn smart, these
workstations.



--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

S O'Neill wrote:
Arny Krueger wrote:


I don't know about other multitracking software, but Audition allows
tracks and portions of tracks to be adjusted by any practical
amount, and to within one millisecond. I've this feature to adjust
for acoustical time delays among microphones, for example.

DP also, as well as Tascam DA-78HR. Both to within one sample. And
there's a plugin called Buffy (IIRC) and a few others that do that
too.

You can time-align data to within one sample in Audtion as well, but not
with the type-in-a-number ease that I was thinking about. From a music
recording standpoint, 1 mSec is more than enough resolution. Sound travels
about a foot in 1 mSec.

I've time-aligned data within a fraction of a sample by upsamping with
Audition, an then doing the alignment with smaller samples. Audition will
upsample to sample rates of 100 MHz or more, so 10 nSec resolution is
possible. I never actually done that as the datasets get kinda large.

This BTW proves that digital data has far better time-domain resolution than
just one sample, because time-aligning within small fractions of a sample,
makes changes that can be technically meaningful.

http://www.pcavtech.com/soundcards/L...644-xfus10.gif shows an
example of the results a high-sample-rate alignment. The ambiguity of the
measurement is stated to be 9 degrees, which is actually 1/20th of a 44100
Hz sample.

The files were upsampled 20x, time-aligned to within one sample, and
downsampled and the relative phase was measured. Thus any large-scale
midband time delays were vastly reduced, and we have a plot of just the
UUT's phase shift.

"Tommi" wrote in message .. .
"Listendave" wrote in message
. ..

Why doesn't anyone talk about this problem? Am I just missing something
here?

I can only say that latency will never be zero, no matter how much we want
it to be.
1 ms is extremely good, 2 is still good. It will never be zero...

right...because then it wouldn't be latency anymore!

In article znr1080878209k@trad,
(Mike Rivers) wrote:

In article writes:

All converters do not have the same delay.

That's why the software needs to be adjustable.

Not only that, but it has to be able to inquire what converter is
hooked up, and know its throughput delay. Damn smart, these
workstations.



--
I'm really Mike Rivers )
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me he double-m-eleven-double-zero at yahoo

Wouldn't it be nice to have an open protocol for talking to your A/D and
D/A converters. Then just put query functions into the protocol for asking
the converter what it's throughput delay is. At that point, the
workstation software is trivial.

Ralph & Diane Barone wrote:

Wouldn't it be nice to have an open protocol for talking to your A/D
and D/A converters. Then just put query functions into the protocol
for asking the converter what it's throughput delay is. At that
point, the workstation software is trivial.

Trouble is, delay through the converters is only part of the story.

I think that most people really want to know the delay from the point where
data is played back from an application playback buffer, to the point where
data is recorded into a application recording buffer. Many things affect
this besides the delay through the converters.

"Arny Krueger" wrote in message
...
Ralph & Diane Barone wrote:

Wouldn't it be nice to have an open protocol for talking to your A/D
and D/A converters. Then just put query functions into the protocol
for asking the converter what it's throughput delay is. At that
point, the workstation software is trivial.

Trouble is, delay through the converters is only part of the story.




I think that most people really want to know the delay from the point
where
data is played back from an application playback buffer, to the point
where
data is recorded into a application recording buffer. Many things affect
this besides the delay through the converters.

Loopback test? It basically tells you what you need to know...

Romeo Rondeau wrote:
"Arny Krueger" wrote in message
...
Ralph & Diane Barone wrote:

Wouldn't it be nice to have an open protocol for talking to your A/D
and D/A converters. Then just put query functions into the protocol
for asking the converter what it's throughput delay is. At that
point, the workstation software is trivial.

Trouble is, delay through the converters is only part of the story.

I think that most people really want to know the delay from the
point where data is played back from an application playback buffer,
to the point where data is recorded into a application recording
buffer. Many things affect this besides the delay through the
converters.

Loopback test? It basically tells you what you need to know...


Agreed. Just use a multitrack editor like Audition to re-record an impulse
that you are playing back. Thing is you can get seems like dozens of
different numbers depending on test conditions.

I've time-aligned data within a fraction of a sample by upsamping with
Audition, an then doing the alignment with smaller samples. Audition will
upsample to sample rates of 100 MHz or more, so 10 nSec resolution is
possible. I never actually done that as the datasets get kinda large.

This BTW proves that digital data has far better time-domain resolution than
just one sample, because time-aligning within small fractions of a sample,
makes changes that can be technically meaningful.



This is true if there is proper dithering.

Dithering makes a digital path IDENTICAL to a bandlimited analog path
with a noise floor.


Mark

Mark wrote:
I've time-aligned data within a fraction of a sample by upsamping
with Audition, an then doing the alignment with smaller samples.
Audition will upsample to sample rates of 100 MHz or more, so 10
nSec resolution is possible. I never actually done that as the
datasets get kinda large.

This BTW proves that digital data has far better time-domain
resolution than just one sample, because time-aligning within small
fractions of a sample, makes changes that can be technically
meaningful.

This is true if there is proper dithering.

Dithering helps, but is not an absolute necessity for these kinds of changes
to be apparent.

Dithering makes a digital path IDENTICAL to a bandlimited analog path
with a noise floor.

Ain't that nice?

;-)