Yup. No risk and no resources, no gain :-) But given what I have (and what is within reach with a stack of RPis), it seems well worth it to try.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.
Indeed, that sounds like my starting place. I have to admit that I like the zita-njbridge approach more, because that way, since I am definitely resampling before it hits the audio hardware, it is only a very simple 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. If zita-njbridge treats zero input in the stream as silence, the overall benefit should be enormous :-)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.