[LAU] Multiple asynchronous JACK chains resampled?

[Chris Caudle]

On Tue, February 23, 2016 9:35 am, Jonathan Brickman wrote:
> What I want to do, is to use the resources I have to run multiple signal
> generation and processing chains asynchronously, in parallel, and then
> use the final audio-hardware-synchronized chain to resample them all
> into one, perhaps using the Zita tools.

I think you may be confusing two different concepts.
Running in parallel
running asynchronous processing

You can run multiple independent synchronous processes in parallel, which
is probably what you want.  Using jack2 should allow that, but you have to
check the connection graph to make sure it is happening.  The original
description you gave was not very detailed, are the Yoshimi instances just
connected to the jack output and that is all?  Is there any stage where
both Yoshimi instances connect that would become the processing limit for
the period?

> use the final audio-hardware-synchronized chain to resample them all
> into one, perhaps using the Zita tools.

Resampling will always add additional latency.  Having unsynchronized
streams that have to be synchronized will always add additional latency.
The zita-nj (network to jack) tools describe this very well in the man
page excerpt below.

I don't recall you relating what current latency setting you are using. 
If you are contemplating some complicated scheme which is going to add
additional processing overhead and additional latency anyway, have you
tried just increasing the buffer size?  That is very simple to try and may
be all you need.

>From man zita-njbridge:
When connecting two Jack systems with unsynchronised
periods the minimum additional latency under worst case
conditions is the sum of the two period times. Additional
latency means any latency required to make the connection
work without interruption. The round-trip latency from an
ideal (zero excess latency) analog input on the sender to
an ideal (idem) analog output on the receiver will be twice
this value. Worst case conditions means that the both sender
and receiver can run at arbitrary times within their
respective periods.

Zita-njbridge is designed to provide a defined and constant
additional latency. The target value is the sum of the two
periods, plus resampling delay, plus any extra buffering
specified by the user. The actual latency will be this value
plus the average network delay.

-- 
Chris Caudle