Re: [Jack-Devel] libjack vs server [ was Re: stepping down
On Mon, Feb 1, 2016 at 10:46 AM, Stéphane Letz <[hidden]> wrote:
> >
> > A server solves this problem by keeping jack as a seperate process that
> is
> > not dependant on any other process to keep it alive.
> >
> > Can you expand on how you would solve this with library instead of a
> server?
> >
> >
> > Yes, that's an interesting programming challenge. It's probably very hard
> > to make this work decently, but the thing is that if you want to run
> several
> > clients at the same time, you will still have the option of starting a
> "main client"
> > first, same way as you run jackd now. What I was replying to in this
> thread,
> > was if you want run a DAW, you very often only want to run one client,
> and
> > then you don't need to start jackd and qjackctl.
> >
>
>
> Before this discussion becomes too crazy… (like : "let's redesign JACK
> yet again… but without anyone to ever implement this new/better/fabulous
> new stuff….) Kjetil I would suggest you read this old paper (2009) on
> JACK2 design, that answers some of your questions :
>
> http://lac.linuxaudio.org/2009/cdm/Thursday/01_Letz/01.pdf
>
>
Both you and Paul have done amazing work which I'm very grateful for.
But I'm not suggesting a redesign here, just a fairly minor change.
Would it be that much work to put jackd into libjack?
That's the first step. I also suggest creating a formally defined api for
error messages so that the clients can show what's going wrong if
a driver fails. I also suggest to rewrite some parts of qjackctl and add it
to
the jack packages as external executables that can be launched by libjack.
This modified version of qjackctl will now not be linked to libjack, but
instead
communicate with libjack through sockets, just plainly doing GUI operation
for whoever client that needs it. This might be a larger job though, but
probably doable over a couple of weekends or so.
1454321847.24836_0.ltw:2, <CAC6niEJ8oWKn65w+-WEQ33o3BGyi0V==Mjt6ryuvB=O9+EEdTg at mail dot gmail dot com>