[Jack-Devel] Cannot combine audio devices with more than 64 channels

[Fons Adriaensen]

On Wed, Jan 25, 2017 at 03:19:14PM +0100, Jörg Müller wrote:

> In your first mail, you write
> > Zita-ajbridge will detect the relative period phases, and insert
> buffering so as to ensure that the difference in latency is always the same.
> That sounds to me like the two cards get additional latency, but it will be
> exactly the same so their outputs remain in correct phase.
> 
> However, in your second mail, you write:
> > Without resampling the samples will not be modified, but the latency of
> the two cards will not be the same (but the difference will be repeatable).
> That sounds like the very opposite.
> 
> So will there be any additional latency when using zita? Can it be
> configured to be the same for all cards? Could the latency be configured to
> something minimal like 64 samples?

Let's assume that you configure Jack to use soundcard A, and then
run zita-j2a using card B, word-cloclk synced to A, to have
additional outputs. 

Zita-j2a is just a Jack client like any other. Even if cards A
and B are configured to use the same period size (this is not
required) the period timing of B w.r.t A is completely random.
So this would introduce a random additional latency on the
outputs of B.

What zita-j2a does in this case is to remove the random part.
Since the periods are not synced, there must be some buffering
between Jack and B. Zita-j2a will adjust the amount of buffering
so as to make the additional latency independent of the random
relative period timing. 

When zita-j2a is resampling this compensation is very accurate,
as the error of the additional delay compared to a fixed target
value is what is driving the resampling ratio. 

When zita-j2a is configured to not resample, the delay adjustment
is made once when the first measurement is available, and fixed
thereafter. This single, first measurement will not have the same
accuracy as the filtered value used when resampling.

The result of this is that if you want a the additional latency
to be very well defined (i.e. having the same value each time
you run the system) the best option is to enable resampling.

Zita-a2j/j2a do set the port latencies so that apps like Ardour
can take them into account. The value may not be sample-accurate,
(it depends on unknown hardware parameters as well) but any error 
on it will be repeatable, so you can measure it once and then rely
on the measured value.

Ciao,

-- 
FA

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)