Re: [LAU] Multiple asynchronous JACK chains resampled?

On Tue, Feb 23, 2016 at 11:38 AM, Jonathan Brickman <jeb@email-addr-hidden>
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.

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Feb 23 20:15:02 2016