On Mon, Feb 1, 2016 at 10:46 AM, Stéphane Letz <letz@grame.fr> 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.