On Tue, Feb 23, 2016 at 11:38 AM, Jonathan Brickman <jeb@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
