<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 10:46 AM, Stéphane Letz <span dir="ltr"><<a href="mailto:letz@grame.fr" target="_blank">letz@grame.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> A server solves this problem by keeping jack as a seperate process that is<br>
> not dependant on any other process to keep it alive.<br>
><br>
> Can you expand on how you would solve this with library instead of a server?<br>
><br>
><br>
> Yes, that's an interesting programming challenge. It's probably very hard<br>
> to make this work decently, but the thing is that if you want to run several<br>
> clients at the same time, you will still have the option of starting a "main client"<br>
> first, same way as you run jackd now. What I was replying to in this thread,<br>
> was if you want run a DAW, you very often only want to run one client, and<br>
> then you don't need to start jackd and qjackctl.<br>
><br>
<br>
<br>
</span>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 :<br>
<br>
<a href="http://lac.linuxaudio.org/2009/cdm/Thursday/01_Letz/01.pdf" rel="noreferrer" target="_blank">http://lac.linuxaudio.org/2009/cdm/Thursday/01_Letz/01.pdf</a><br>
<br></blockquote><div><br></div><div>Both you and Paul have done amazing work which I'm very grateful for.</div><div>But I'm not suggesting a redesign here, just a fairly minor change.</div><div>Would it be that much work to put jackd into libjack?<br></div><div>That's the first step. I also suggest creating a formally defined api for</div><div>error messages so that the clients can show what's going wrong if</div><div>a driver fails. I also suggest to rewrite some parts of qjackctl and add it to</div><div>the jack packages as external executables that can be launched by libjack.</div><div>This modified version of qjackctl will now not be linked to libjack, but instead</div><div>communicate with libjack through sockets, just plainly doing GUI operation</div><div>for whoever client that needs it. This might be a larger job though, but</div><div>probably doable over a couple of weekends or so.</div><div><br></div></div></div></div>