[LAU] Multiple asynchronous JACK chains resampled?

Chris Caudle chris at chriscaudle.org
Tue Feb 23 17:51:31 UTC 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






More information about the Linux-audio-user mailing list