On Sun, Jan 31, 2016 at 5:12 AM, Spencer Russell <sfr@media.mit.edu> wrote:

I agree JACK probably isn’t the right solution for your basic DAW user. That said, I think there’s great value in the general paradigm of separating the routing from the applications. As an application developer, it’s great to just expose your ports and make routing Somebody Else’s Problem.

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

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

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.