Re: zita-a2j and capture alignment

Ben Bell <[email protected]>
Newsgroups gmane.comp.audio.ardour.devel
Message-ID <[email protected]>
On Sat, Sep 07, 2013 at 03:00:57PM +0000, Fons Adriaensen wrote:
> 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.
I believe there's a long standing issue with alsa todo with assuming that
the interrupt on one card firing means that the buffers are ready on both
cards. Something like that, but there's a long history of problems with
it on this list and other places.

> > 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
OK, great.

> > 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. 
I forget... does it set the hardware flag too? I hacked something to do
that but can't remember if it was alsa_in or zita-a2j,

> Zita-a2j always resamples, it doesn't know that the cards are synced.
I think I vaguely remembering you once wondering out loud about making
an option for disabling resampling. Any chance of that? :)

> 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, 
Yes. In the mean time there's the possibility of using two zita-a2j
instances talking to a jack with a dummy back end, but then everything
would be resampling which really does undermine the whole idea of jack
giving sample-accurate recording.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.