1 Feb
2016
1 Feb
'16
1:39 a.m.
On Sun, Jan 31, 2016 at 11:10 PM, Paul Davis <paul(a)linuxaudiosystems.com wrote:
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,
And that's what I'm suggesting. One well known point of control, provided
by libjack, which every
client can use, if they want.
as well as the capability to start the server from scripts etc.
Sure, there's nothing wrong creating a dummy-client that only runs the
server, if you need that.
> > >
>>> 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.
This is so flaky and uncertain. Layers upon layers of software, which all
may fail.
The end result is that there is a higher chance for the user to not get the
information
he needs, plus the added complexity and frustration. libjack should take
care of all this.
On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <
k.s.matheussen(a)gmail.com> wrote:
You want to see which options jack has been started with. You want this
information
visible in an obvious way. It is both undocumented and flaky to have to
"run ps -Af|grep jackd" or something like that to get this information.
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.