Re: [linux-audio-dev] Random thought on HDR latency compensation

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Random thought on HDR latency compensation
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Apr 19 2000 - 21:46:48 EEST


>Maybe those of you (Paul, Kai, others?) working on projects that
>provide hard-disk recording have already solved this problem, but
>this just occurred to me (I have a habit of having irrelevant ideas
>in the middle of trying to meet a deadline!):

This is already fully implemented in Ardour. You get to set a
configuration file variable called "capture offset", which describes
any extra latency in your system other than the one created by the
audio interface h/w and ardour's own buffering. For instance, my
digital mixer adds about 1.3ms. You will need a separate program to
measure this, or you can use manufacturer's numbers or you can
estimate it.

Ardour automatically compensates for the combined delay, and puts
newly-recorded material at the correct point on the "tape". Correct is
defined as the latency created by the audio h/w plus ardour's own
buffer (there isn't any right now) plus the specified capture offset.

As an example: suppose you are using a total of 256 samples of space
in the audio h/w buffer, plus you have an extra 50 samples of delay
introduced by other digital devices between the disk and the monitor.
You set capture_offset to 50, and start recording from the beginning
of the tape. Ardour will write the 306th recorded sample to sample #0
in the recorded file, 307->1, 308->2 etc.

It is this *exact* problem which made x-fade at punch in/out so hard
to do. Anyone with an ounce of programming skill could have written a
system which did x-fade with existing material when the x-fade was
happening at the same place as the playback would happen from. Whats
hard is that the x-fade happens at some point after we've played back
material that will need to be x-faded.

Anyway, thats what ardour now does, so to give another example: same
parameters as above, but you punch in (start recording) at the time
when playback sample #1000 is being played. That means that ardour's
internal playback location is 10306. However, it will compute the
crossfade between the existing material on the tape and the new stuff,
with the crossfade starting exactly at sample #1000 on the tape.

I am not totally certain that my computation of the capture location
on the tape is correct, but I have certainly designed ardour right
from the start to work this way. I am also almost certain that the
current clock display shows ardour's own internal playback location,
not the one corresponding to the audible output, so there are still
some minor tweaks needed in these areas.

There is also a per-track delay, but it is not yet implemented other
than in the GUI.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Apr 19 2000 - 22:21:19 EEST