Re: [LAU] Multiple asynchronous JACK chains resampled? - Linux-audio-user

23 Feb 2016

On Tue, February 23, 2016 11:40 am, Jonathan Brickman wrote:
...
  and short chain -- IP inputs to zita-njbridge to
hardware -- which has
 to be synchronous with the physical audio chipset.  So the DSP %
 usage on the hardware-connected chain becomes low, because
 it is as simple as it is, and each of the chains in action have a lot
 less also, distributing the work carefully. 
This seems like a pretty complicated scheme.  What is your actual end goal?
What do you want to happen differently than your current situation?

Is it just that at 85% DSP usage your system is not capable of running
anything additional, and you want to run additional processes?
If that is all, then first try adjusting the latency of your current setup
to be equivalent to the latency you will have with the Rube Goldberg setup
of a stack of dinky little ARM processors connected together with
resampling through a network.

If you read the zita-njbridge man page you see that the minimum latency is
the sum of the periods of each asynchronous connection, so at minimum
double your current latency, plus resampling latency, plus network delay.

So for a start set your system latency to 2x or 3x what you currently have
and see how that works.

-- 
Chris Caudle