[Ardour-Dev] zita-a2j and capture alignment

Paul Davis paul at linuxaudiosystems.com
Tue Sep 10 06:12:27 PDT 2013

On Tue, Sep 10, 2013 at 9:05 AM, Fons Adriaensen <fons at linuxaudio.org>wrote:

> On Tue, Sep 10, 2013 at 08:32:51AM -0400, Paul Davis wrote:
> > Ardour cannot correct the case where the source (the JACK backend or
> zita)
> > are not in agreement. Sorry, this is asking for the absurd. The regions
> are
> > not a different length - they contain different data. Pop up the region
> > properties editor (right click on a region > properties) to establish
> this.
> > Their data is different because there is a skew between the two sources.
> > Nothing ardour can do (or know) will improve this.
> So how (if at all) does ardour use the capture latency values when
> recording ?
> Suppose you have two identical sound cards. One is used by Jack's backend,
> the other by zita-a2j. Both set the correct capture latency value on their
> ports. For a2j this will of course be a higher value than for the backend.
> Connect the same signal to the two cards, record two tracks simultaneously,
> one from each card.
> I'd expect the two resulting regions
> * to be in sync when played back,
> * to have different start/end points.
> assuming ardour uses the capture latency values to offset the regions.
> If not, how are the latency values used ?

in general, ardour's transport control for recording uses worst case
numbers, not per-track numbers (we do not have per-track transport
position). so we will keep recording for long enough to catch the last
incoming data after the stop-recording request was noted, which may result
in less/more data being captured in some tracks compared to others that
started "late" because their own latency varied.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20130910/a976e4e6/attachment-0002.htm>

More information about the Ardour-Dev mailing list