Re: zita-a2j and capture alignment
Paul Davis <[email protected]>
| Newsgroups | gmane.comp.audio.ardour.devel |
|---|---|
| Message-ID | <CAFa_cK=ugbUSZLa=0zTkeumv1=k-nSiC2mDuDAFMmWbkZyW-1A@mail.gmail.com> |
On Tue, Sep 10, 2013 at 9:05 AM, Fons Adriaensen <[email protected]>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. _______________________________________________ ardour-dev mailing list [email protected] http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org