<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote
cite="mid:CAFa_cK=U8spfBh8C1WyZNpuEYvFL_QCuvWnfNZH1LVVos0YZ1w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class=""></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>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CAFa_cK=U8spfBh8C1WyZNpuEYvFL_QCuvWnfNZH1LVVos0YZ1w@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
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 :-)<br>
<br>
<div class="moz-signature">-- <br>
<div style="color: #993300; font-size: 0.8em; font-style: italic;">
Jonathan E. Brickman <a class="moz-txt-link-abbreviated" href="mailto:jeb@ponderworthy.com">jeb@ponderworthy.com</a> (785)233-9977<br>
Hear us at <a href="http://ponderworthy.com">http://ponderworthy.com</a>
-- CDs and MP3 <a
href="http://ponderworthy.com/ad-astra/ad-astra.html">now
available!</a><br>
Music of compassion; fire, and life!!!
</div>
</div>
</body>
</html>