On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <paul@linuxaudiosystems.com> wrote:

On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <k.s.matheussen@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?

 

 

Well, I've never used it. It doesn't feel safe. There is no obvious place to

check that it does what it's supposed to.

 

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?

If only one program produces sound, why would you also want to start a server?

, plus that it

would provide an enormous number of fun and interesting programming challenges

for the implementors of that functionality.

But my point is that you don't need the jackd program. Every client is also a potential

server (although the user doesn't know this), and since libjack provides functionalities for

configuring jack the same way for all clients, jackd is not needed. This way we can also

create formally specified error messages for the clients. Currently, if something goes

wrong, you have to dig around in the "messages" window in qjackctl, which may contain

some information that could help you make things work. It's really bad actually.