[Jack-Devel] stepping down

[Paul Davis]

On Sun, Jan 31, 2016 at 3:48 PM, Kjetil Matheussen <k.s.matheussen at gmail.com
> wrote:

>
>
> On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <paul at linuxaudiosystems.com>
> wrote:
>
>>
>>
>> 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?
>>
>>
>
> 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?
>>
>
> 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.


>
> , 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160131/03879e99/attachment.html>