[Jack-Devel] stepping down

Paul Davis paul at linuxaudiosystems.com
Sun Jan 31 14:44:42 CET 2016

On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <k.s.matheussen at gmail.com
> wrote:

> I don't think Jack is the wrong solution for a DAW either. But Jack never
> got finished.
> It has a wonderful API, but it shouldn't be a struggle for a program to
> create a jack client
> if a jack server isn't running. (there were a lot of talk about this
> around 10 years ago,
> but the end result never became as good as it should I think).

i am not sure what the problem is here. if the client doesn't specify
anything, then the server will start automatically with the same parameters
as it did last time. this has worked for years. no?

> I think the first program trying to create a client also should start the
> server. Not
> just fork off a process, but actually run the server.
> And if another program wants to create a jack client, it connects to the
> first client process,
> which is the one running the server.

this seems a bit odd to me. if the first client is really just a client,
why would it become the server? what happens when the user closes it (or
otherwise resets it)?

that's the whole point of using a control application that exists before
(and almost certainly after) all other clients.

> Furthermore, GUI should be built into libjack, so that you can call
> jack_open_audio_driver_configuration_gui(),
> jack_open_audio_connection_configuration_gui(),
> etc. inside your client.
> I know there is something called libjackserver, but how many uses it?

libjackserver isn't what you think it is. you're thinking of the server
API, used to start, stop and otherwise control a JACK server. it is the
basis of jack2's dbus support, so basically everything using jack2 is using
it. it is also present in jack1, and is also used internally there.

libjackserver is also used *all* the time.

Does it do
> all these things? How stable is it? In my opinion, there shouldn't
> be any libjackserver, or jackd program, or qjackctl, only libjack.

this would simply lead *back* to jackd, since lots of people would want a
program they could start in order to start jack, that would run before and
after other clients. someone would write it, link it to libjack and it
would become "jackd".

> Another problem with Jack is that it never attempted to do consumer audio,
> and then we got pulseaudio in addition to Jack. There should only be Jack,
> IMO.

here we sort of agree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160131/eaaec439/attachment.html>

More information about the Jackaudio mailing list