<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 4:39 PM, sqweek <span dir="ltr"><<a href="mailto:sqweek@gmail.com" target="_blank">sqweek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 1 February 2016 at 22:31, Kjetil Matheussen <<a href="mailto:k.s.matheussen@gmail.com">k.s.matheussen@gmail.com</a>> wrote:<br>
<br>
>>> to fail. For instance didn't the messages window in the windows version<br>
>>> of qjackctl show anything<br>
>>> coming from jackd until autumn 2015.<br>
>><br>
>> that has to do with windows and qjackctl, not with jackd.<br>
><br>
> But it illustrates how flaky the system is when a bug like this can exist<br>
> for 10 years.<br>
<br>
</span>No, a 10 year old bug illustrates nothing but the nature of open<br>
source. For a bug to be fixed it must (a) be encountered (b) be<br>
reported and (c) receive developer attention. (a) & (b) is extremely<br>
hard for qjackctl on win32 because the majority of the userbase is on<br>
a different platform. Hats off to yourself for stepping up to fill (c)<br>
and giving win32 some much needed attention, but this doesn't make<br>
jackd "flaky".<br>
<br></blockquote><div><br></div><div>I understand why things are like they are. I'm not claiming anyone has done</div><div>a bad job. Absolutely not. I just point out that things can be better. Had there been</div><div>a libjackserver library, where the server itself had been included,</div><div>qjackctl could have linked to that library instead of starting a process</div><div>and do very informal and flaky communication between the server</div><div>and the GUI.</div><div><br></div><div>(Oh, and regarding the qjackctl bug. I didn't only do (c), I also fixed</div><div>the bug itself)</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Your proposal doesn't make sense in general. It's narrow minded and<br>
very focused on the GUI application use-case.</blockquote><div><br></div><div>No, it's not. I'm proposing to put the jack server into a library, preferably</div><div>libjack. jackd wouldn't stop to exist because of that.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Anyway, a separate process makes the whole system *more* robust, not<br>
more flaky. If the jack server is running in the same address space as<br>
a client, then an error in that client (segfault/buffer overflow/etc)<br>
can bring down the entire audio system.<br>
<br></blockquote><div>But I'm not proposing to remove jackd. If you want to continue using</div><div>jackd, you can.</div><div> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It sounds like the existing configuration mechanism provided by jackd<br>
enables you to do what you want already (ie. running ~/.jackdrc). You<br>
can do literally whatever you want in this script. You don't have to<br>
run jackd directly, you can write a GUI frontend that lets you<br>
configure options before launching jackd and make ~/.jackdrc launch<br>
*that*. </blockquote><div><br></div><div>That's all good. But as I've pointed out, there's no proper way to find</div><div>out what's really happening. libjack should have a 'char *jack_info()' function</div><div>that clients can display, as a minimum.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The best part about this is that it just works with no change to<br>
jackd, no change to libjack, and no change to any clients. This is<br>
UNIX philosophy. We have simple tools and we glue them together. And<br>
the result is beautiful.<br>
<br></blockquote><div>And I'm proposing to extend that thought further by putting the server part</div><div>of jackd into a library.</div><div><br></div><div><br></div></div></div></div>