[LAU] Multiple asynchronous JACK chains resampled?

[Paul Davis]

On Tue, Feb 23, 2016 at 11:38 AM, Jonathan Brickman <jeb at ponderworthy.com>
wrote:

>
>
>
>
> I do understand that JACK is designed to be completely synchronous.  But a
> good pipelined architecture, can take multiple synchronous processing
> chains running independently (asynchronously to each other), and then merge
> them at the output end.
>

That implies (a) extra CPU load (b) possible loss of quality.


> What I want to do is the equivalent using JACK at the synchronous level,
> so that I take advantage of more of my computing power.  Eventually I will
> want to do exactly the same using four or five RPi-compatibles, with just
> one of them having the audio output;
>

Doing this correctly would imply using a single word clock distributed to
all your R-Pi's. But I doubt that you're going to do that. Instead, you're
going to try to distribute the "JACK clock".

You have two choices:

(1) try to use one of the implementations of netjack, which effectively
distributes the "JACK clock" across the network
(2) the "other" zita tool,  zita-njbridge, which is a client that
sends/receives audio over a (local) network and resamples as necessary. You
will still need to run JACK on each R-Pi and decide what to use as the
clock via your choice of backend. No clock sync is assumed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20160223/06f08465/attachment.html>