Subject: Re: [linux-audio-dev] Random thought on HDR latency compensation
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Apr 20 2000 - 19:40:22 EEST
In message <38FE7EEB.2A939D63_AT_snowcrest.net>you write:
>I think this is important. In fact, the first thing I do when I use a
>new recording environment is to record a single sharp transient to track
>1. Then I route the analog output from track 1 to the analog input of
>track 2, and record on track 2 while playing back track 1. Then I zoom
>in to single sample resolution and drag track 1 until the waveforms are
>alligned. The full duplex latency is equal to the number of samples
>that track 1 has been dragged.
Right, this is one way to measure the "capture-offset" variable for ardour.
>This issue will probably become more important as the hdr, mixing, and
>plug-in activities merge. Before the pre-existing track can be heard,
>it must first move through the mixer and any plug-ins applied to that
>track. Often more than one track of pre-existing material will be
>played back simultaniously, and each track may have different plug-ins,
>or a different number of plug-ins. This means that each track will play
>back with a different amount of latency.
Absolutely not. Plugins have no effect on latency whatsoever. Any
plugin system that allows this is incorrectly designed. The closest
they can get to affecting it would be by being a delay line with a
100% wet signal. But thats not the same thing at all.
This is not to say that ardour could not handle different latencies
for different tracks, just that it doesn't happen that way when you
add plugins. The data for the next section of sound is computed while
the previous one is playing. If it takes too long to do this
computation, you don't have an increase in latency, you have a dropout.
>Musicians don't monitor from the playback head but recording engineers
>do. This is called confidence monitoring, because the recording
>engineer can be confident that what he hears is exactly what has been
>recorded, and is a feature that differentiates true pro gear from
>semi-pro or consumer gear. I would want this feature in my next
>recording environment.
This is not true of HDR systems. Its a requirement of tape based
systems, because of the variability of the tape medium and the
transport mechanism. In an HDR environment, as others have pointed
out, if what goes onto the disk is not what you meant it to be, you've
got much bigger problems than the monitoring point.
In addition, as I noted in my previous reply to Paul Winkler,
re-reading data from the disk after recording it will increase the
required disk throughput to a point that cannot be satisfied by
anything except the most current disks and controllers.
--p
This archive was generated by hypermail 2b28 : Thu Apr 20 2000 - 20:12:33 EEST