[Ardour-Dev] zita-a2j and capture alignment

Fons Adriaensen fons at linuxaudio.org
Sat Sep 7 08:00:57 PDT 2013

On Sat, Sep 07, 2013 at 03:27:21PM +0100, Ben Bell wrote:

> In my continued quest to use a pair of clock-synched Delta 1010 cards
> together to record a whole live band I've recently been using zita-a2j rather
> than the alsa pcm_multi approach. It is much less prone to xruns and generally
> works well

I'm surprised that pcm_multi creates such problems, what it does is 
a lot simpler than what happens in a2j. If the cards are synced it
should just work.

> but I've still got a couple of niggles/questions.

> 1) How do the -n/-p parameters relate to their counterparts in jack? Should
>    I be specifying exactly the same -n/-p pair for the closest sync?

No, there is no required relation between those. For minimal additional
latency, use a period on the ALSA device that is smaller than the one
used by Jack. The thread that uses the ALSA device in a2j runs at a higher
priority than Jack's threads to make this work.

> 2) When I capture a mix of jack driven and zita-a2j driven inputs, the
>    alighment is out. I don't just mean audio latency, I mean that the
>    captured regions have different start times. I'm guessing something is
>    trying to be smart about re-aligning the two sources but it's not
>    getting it right.

That is probably what is happening. Zita-a2j doesn't set any latency
values on its Jack ports, and it should really do that. I'll look 
into it. Adding a command line option should be easy, and will
probably solve the practical problem. 

Note that if a2j would report the correct latency, the tracks would
still have different start points, but the other way around. If that
is a problem, even if the signals are in sync, the only solution would
be to use explicit delays.

> Note that I'm running these cards clock synched at the same sample rate so
> that oughtn't be an issue.

Zita-a2j always resamples, it doesn't know that the cards are synced.

The real solution would be a Jack backend that allows more than one
ALSA device to be used, provided they have the same clock. Then, 
giving them the same period size and staring them as close together
as possible things should work. But such a backend would essentially
try to do the same as pcm_multi, just in a different (and probably
less efficient) way. I once wrote a Jack backend using zita-alsa-pcmi,
as a test case, it should be possible to extend that.



A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

More information about the Ardour-Dev mailing list