1 Feb
2016
1 Feb
'16
3:17 a.m.
On Mon, Feb 1, 2016 at 10:46 AM, Stéphane Letz <letz(a)grame.fr> wrote:
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.
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