<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 11:38 AM, Jonathan Brickman <span dir="ltr"><<a href="mailto:jeb@ponderworthy.com" target="_blank">jeb@ponderworthy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <br><div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <br>
    <br></span>
    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. </div></blockquote><div><br></div><div>That implies (a) extra CPU load (b) possible loss of quality.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> 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;</div></blockquote><div><br></div><div>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". <br><br></div><div>You have two choices: <br><br></div><div>(1) try to use one of the implementations of netjack, which effectively distributes the "JACK clock" across the network<br></div><div>(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.<br></div><div> <br></div></div><br></div></div>