<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
For those who may be interested, I am seeing the first small
glimmering of what looks like real success, in running multiple JACK
servers on one box for the purpose of distributing DSP load. I can
now reliably have two netjack1 slaves connect to one netjack1
master, the master running ALSA to hardware, all within one Linux
box under one kernel and one filesystem.<br>
<div class="moz-forward-container"><br>
The way that this works is "containerization" or "sandboxing",
which can give an IP to anything ranging from one running binary
to a large collection. I started the current effort using Docker
containerization, but its standard setups require a lot of
filesystem recreation, each Docker container has an entire working
OS filesystem apart from the kernel; but during the studies for
Docker, I blundered into something else called firejail, and
firejail appears to be just what the doctor ordered, it seems to
do just about everything while using the existing filesystem, and
one can very easily turn off the features one doesn't need. <br>
<br>
To cut to the chase, after boot and system prep, first one creates
an IP bridge:<br>
<blockquote><tt>sudo brctl addbr br0<br>
sudo ifconfig br0 10.99.99.1/24<br>
</tt></blockquote>
and then starts JACK in the sandboxes:<br>
<blockquote><tt># The master hardware sandbox is named MASTER, the
QJackCTL profile is named MASTER,</tt><tt><br>
</tt><tt># the JACK server is named MASTER.</tt><tt><br>
</tt><tt>nohup firejail --name=MASTER --noprofile --net=br0
--ip=10.99.99.10 \</tt><tt><br>
</tt><tt> /usr/bin/jackd -n MASTER -m -dalsa -r48000 -p256
-n2 -Xseq -D -Chw:NVidia -Phw:NVidia \</tt><tt><br>
</tt><tt> > ~/LOGS/jack-master.log &</tt><tt><br>
</tt><tt><br>
</tt><tt><br>
</tt><tt># The SRO hardware sandbox is named SRO, the QJackCTL
profile for it is named SRO,</tt><tt><br>
</tt><tt># the JACK server is named SRO.</tt><tt><br>
</tt><tt>nohup firejail --name=SRO --noprofile --net=br0
--ip=10.99.99.15 \</tt><tt><br>
</tt><tt> /usr/bin/jackd -n SRO -dnetone \</tt><tt><br>
</tt><tt> > ~/LOGS/jack-sro.log &</tt><tt><br>
</tt><tt><br>
</tt><tt><br>
</tt><tt># Ditto for STRINGS.</tt><tt><br>
</tt><tt>nohup firejail --name=STRINGS --noprofile --net=br0
--ip=10.99.99.20 \</tt><tt><br>
</tt><tt> /usr/bin/jackd -n STRINGS -dnetone \</tt><tt><br>
</tt><tt> > ~/LOGS/jack-strings.log &</tt><br>
</blockquote>
And then connects the JACK servers, by adding jack_netsource
processes into the existing MASTER sandbox:<br>
<blockquote><tt>#!/bin/bash</tt><tt><br>
</tt><tt><br>
</tt><tt># SRO</tt><tt><br>
</tt><tt>nohup firejail --join=MASTER jack_netsource -s MASTER
-H 10.99.99.15 > ~/LOGS/netsource-sro.log &</tt><tt><br>
</tt><tt><br>
</tt><tt># STRINGS</tt><tt><br>
</tt><tt>nohup firejail --join=MASTER jack_netsource -s MASTER
-H 10.99.99.20 > ~/LOGS/netsource-strings.log &</tt><br>
</blockquote>
I have not tested further yet, no clients -- am working on
something closer to production now -- but this is looking very
good, the connections are reported successful, zero xruns, and on
this prototyping box -- 2.6GHz AMD quad, ten-plus years old --
0.8% DSP in use on all three JACK servers and very low memory
usage. This is considerably better than I had hoped.<br>
<br>
The sandboxed binaries above, cannot reach outside the one box as
written above, but the excellent and very responsive developer of
Firejail has provided <a
href="https://github.com/netblue30/firejail/issues/372">a method</a>.
As a result this could all be done box-independently -- for
instance, if one's "monolith is the building" (going to have to
remember that, Patrick), one could have all indicated motherboards
NFS or SMB to one file server, and then use a central control GUI
machine to run all firejails on whichever hardware was proven most
appropriate, and testing could become much easier. Along the way
I also found 'xpra' likely to be a very good way to setup such a
central control, am going to test that as a side project.<br>
<br>
I tried using netjack2 first, but ran into mystery behavior, xruns
started piling huge when the second slave connected. So I went
with netjack1, especially because
Patrick Shirkey already proved the above paradigm in multibox mode
using netjack1. I am currently using netjack1 under jackd2, but
will change to netjack under jackd1 if a reason to do so appears.<br>
<br>
I am now working on a working dual-JACK prototype, in a
near-production design, as a next step towards a generally
transportable MultiJACK Patch Management methodology and the next
big build of my Box of No Return :-)<br>
<br>
Cheers, and thanks everyone!!!!<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>
<br>
</div>
<br>
</body>
</html>