[LAU] Multiple asynchronous JACK chains resampled?

Jonathan Brickman jeb at ponderworthy.com
Tue Feb 23 17:40:04 UTC 2016


>     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.
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.
>
>     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.
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 :-)

-- 
Jonathan E. Brickman   jeb at ponderworthy.com   (785)233-9977
Hear us at http://ponderworthy.com -- CDs and MP3 now available! 
<http://ponderworthy.com/ad-astra/ad-astra.html>
Music of compassion; fire, and life!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20160223/b6557821/attachment.html>


More information about the Linux-audio-user mailing list