On Mon, Feb 1, 2016 at 4:39 PM, sqweek <sqweek@gmail.com> wrote:
On 1 February 2016 at 22:31, Kjetil Matheussen <k.s.matheussen@gmail.com> wrote:

>>> to fail. For instance didn't the messages window in the windows version
>>> of qjackctl show anything
>>> coming from jackd until autumn 2015.
>>
>> that has to do with windows and qjackctl, not with jackd.
>
> But it illustrates how flaky the system is when a bug like this can exist
> for 10 years.

No, a 10 year old bug illustrates nothing but the nature of open
source. For a bug to be fixed it must (a) be encountered (b) be
reported and (c) receive developer attention. (a) & (b) is extremely
hard for qjackctl on win32 because the majority of the userbase is on
a different platform. Hats off to yourself for stepping up to fill (c)
and giving win32 some much needed attention, but this doesn't make
jackd "flaky".


I understand why things are like they are. I'm not claiming anyone has done
a bad job. Absolutely not. I just point out that things can be better. Had there been
a libjackserver library, where the server itself had been included,
qjackctl could have linked to that library instead of starting a process
and do very informal and flaky communication between the server
and the GUI.

(Oh, and regarding the qjackctl bug. I didn't only do (c), I also fixed
the bug itself)


 
Your proposal doesn't make sense in general. It's narrow minded and
very focused on the GUI application use-case.

No, it's not. I'm proposing to put the jack server into a library, preferably
libjack. jackd wouldn't stop to exist because of that.



Anyway, a separate process makes the whole system *more* robust, not
more flaky. If the jack server is running in the same address space as
a client, then an error in that client (segfault/buffer overflow/etc)
can bring down the entire audio system.

But I'm not proposing to remove jackd. If you want to continue using
jackd, you can.
 

It sounds like the existing configuration mechanism provided by jackd
enables you to do what you want already (ie. running ~/.jackdrc). You
can do literally whatever you want in this script. You don't have to
run jackd directly, you can write a GUI frontend that lets you
configure options before launching jackd and make ~/.jackdrc launch
*that*. 

That's all good. But as I've pointed out, there's no proper way to find
out what's really happening. libjack should have a 'char *jack_info()' function
that clients can display, as a minimum.


 
 
The best part about this is that it just works with no change to
jackd, no change to libjack, and no change to any clients. This is
UNIX philosophy. We have simple tools and we glue them together. And
the result is beautiful.

And I'm proposing to extend that thought further by putting the server part
of jackd into a library.