31 Jan
2016
31 Jan
'16
1:59 p.m.
On Sun, Jan 31, 2016 at 3:48 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
If only one program produces sound, why would you also want to start a
server?
i can think of lots of reasons. but i don't think it matters.
wrote:
>
>
> On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
>
>>
>>
>> On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <
>> k.s.matheussen(a)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.
>
You're sure of that? Every one of your JACK clients explicitly avoids
auto-start?
The mechanism for this is extremely simple and robust. The contents of the
file ~/.jackdrc are executed. You can check the result with ps aux or a
graphical equivalent.
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?
, plus that it
would provide an enormous number of fun and interesting programming
challenges
for the implementors of that functionality.
and no effective difference for users over and above the current auto-start
scenario.
you also missed out how EVERY single possible JACK client now has to have
some way to bring up a server control dialog, that will work no matter what
GUI toolkit the client was written with (or no GUI toolkit).
is this supposed to be a serious suggestion?
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.
a pathway for errors to propagate from server to clients was something
discussed in berlin in 2007.