[Jack-Devel] stepping down

[Paul Davis]

On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <k.s.matheussen at gmail.com
> wrote:

>
>
> I meant server options. Driver name, realtime on/off, driver options,
> timeout, etc.
>

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 ...


>
>
>> 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.
>>
>>
> But it's better than having different GUIs in every client for configuring
> jack.
>

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,
as well as the capability to start the server from scripts etc.


>
>
>
>> what problem are you actually concerned with fixing? what users does it
>> affect? when?
>>
>
> I think I have listed the problems. The far worst problem is that there
> is no proper error response when a driver doesn't start. Especially on
> Windows,
> where qjackctl is quite buggy and portaudio often refuses to start.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160131/3892e32c/attachment.html>