<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 11:10 PM, Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com" target="_blank">paul@linuxaudiosystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <span dir="ltr"><<a href="mailto:k.s.matheussen@gmail.com" target="_blank">k.s.matheussen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div></span><div>I meant server options. Driver name, realtime on/off, driver options, timeout, etc.</div></div></div></div></blockquote><div><br></div></span><div>why does a client want these? it would not contain code to start JACK that required any of this .... unless you're suggesting a different GUI to configure the server in every client, which you're not ...<br></div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>You want to see which options jack has been started with. You want this information</div><div>visible in an obvious way. It is both undocumented and flaky to have to</div><div>"run ps -Af|grep jackd" or something like that to get this information.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div></span><div>I don't anything perfect about jack_lsp popping up a GUI dialog to configure a server. I don't see anything good about a careful constructed GUI application having to deal with the reality of a new dialog being created. this isn't even close to perfect.<br><br></div></div></div></div></blockquote><div><br></div></span><div>But it's better than having different GUIs in every client for configuring jack.</div></div></div></div></blockquote><div><br></div></span><div>I am fairly confident that what is better for most users is having a well known point of control (e.g. cadence, qjackctl) to start and control JACK,</div></div></div></div></blockquote><div> </div><div>And that's what I'm suggesting. One well known point of control, provided by libjack, which every</div><div>client can use, if they want.</div><div><br></div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> as well as the capability to start the server from scripts etc.<br></div><span class=""><div></div></span></div></div></div></blockquote></div><div><br></div><div>Sure, there's nothing wrong creating a dummy-client that only runs the server, if you need that.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>what problem are you actually concerned with fixing? what users does it affect? when?<br></div><div></div></div></div></div></blockquote><div><br></div></span><div>I think I have listed the problems. The far worst problem is that there</div><div>is no proper error response when a driver doesn't start. Especially on Windows,</div><div>where qjackctl is quite buggy and portaudio often refuses to start.</div></div></div></div></blockquote><div><br></div></span><div>Qjackctl arranges to catch all output from the server, which is by far the simplest way to present information to the user, especially in a context where the reasons for failure can be incredibly complex. It might not work as well on Windows as it does on *nix platforms, but I hardly think that this would justify some new mechanism to pass failure information between processes.  <br></div></div><br></div></div>
</blockquote></div><br></div><div class="gmail_extra">This is so flaky and uncertain. Layers upon layers of software, which all may fail.</div><div class="gmail_extra">The end result is that there is a higher chance for the user to not get the information</div><div class="gmail_extra">he needs, plus the added complexity and frustration. libjack should take care of all this.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>