Re: [LAD] Multiple JACK servers connected in one host?

>>
>> although it isn't proven yet .. i think that your problem may
>> come from the fact that you want to have 19 different engines,
>> and you keep flicking switches to go from one to the other.
> Nope, I don't want to switch engines. Everything runs at once, and
> runs very well by the way. I just want to take more advantage of
> what I have, by running some things asynchronously, exactly the
> way some are already doing using multiple motherboards.
>
>
> the "engines" i'm referring to are your many multiple clients (19 or so).
OK. I am not flicking switches to go from any to any other. I am
sending MIDI events, which are triggering synths, and sending data along
JACK paths which do not and are not changed after they are built, as
long as the box runs. That's why it's called "Concurrent Patch
Management" (
http://lsn.ponderworthy.com/doku.php/concurrent_patch_management ).
> i think you're still confused by terminology here, in a way that
> doesn't advance your situation. Nothing in a JACK system runs
> "asynchronously". Everything is "synchronous", which means that within
> a given process cycle, all clients will be processing audio samples
> taken from, or to be written to, the same locations in the hardware
> buffer of the audio interface in use. They work on the same "time
> slice". Changing this would break the fundamental assumptions and
> design of JACK (all versions).
No, I know very well that nothing in a single JACK system runs
asynchronously. The point is that if a single JACK system cannot be
flexible enough to use most of the computing power I have, because of
the limitations of any synchronous design, multiple JACK systems will be
employed within the one box, just as others already employ multiple JACK
systems on multiple motherboards to serve the same purpose. I am hoping
to avoid having to run each JACK system in its own Docker container, and
at least in theory, it should be possible to do this using netjack1,
netjack2, or jacktrip, but it appears that either localhost may not have
been tested very much as a network for these, or there may be another
limitation somewhere of which I'm not aware which prevents that from
working.
> what you are talking about is parallel vs. serialized execution of
> clients (which some might term "sequential execution"). parallel
> execution means that clients can be distributed across cores or cpus
> or whatever; serialized execution means that only 1 client can execute
> at a time, so unless that client has its own internal processor-level
> parallelism (e.g. ardour), it will make no difference how many
> cores/cpus/mobos you have - only 1 of them will be used at a time.
No, I am not. I am talking about expanding the paradigm at large, to
use available resources, however it can be done.
> your workflow has some parallelizable elements and some elements that
> must be run serially/sequentially. it is an odd design, significantly
> outside the intended scope of what JACK was intended to be used for.
> some people think it can be made to work for a flow like this.
In point of fact it works very nicely right now, as far as it can. I
have to admit that I don't care how JACK was intended to be used; I care
merely what it can do. Certainly the tools which the Wright brothers
used in 1903 were never designed to build airplanes :-)

-- 
Jonathan E. Brickman   jeb@email-addr-hidden   (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!!!

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Mar 11 20:15:03 2016