[Jack-Devel] Client-Server models are just fine. Please?

[Jörn Nettingsmeier-5]

Hi *!


Funny to see the recent activity prompted by Paul's step-down notice.
I'm a bit worried to see this flurry of fundamental design discussions
about putting everything into some magical lib and whatnot.

Client-server thinking is a fundamental prerequisite for keeping one's
sanity when using UNIX (and Mac OS X, for that matter), and it even
benefits Windows users. Client-server architecture is good. It works.

Nothing against automating things, but if your user-friendly application
feels it must spawn a jack server for me, it needs to do all of the
following:

* pop open a notice to the effect that no jack server has been found and
does the user want you to do that for her/him? together with a checkbox
to not ask again and a notice on how to undo the "don't ask again".

* spawn a jackd server and explain to the user how it guessed what
configuration to use and how to change that. also point out to the user
how to see/modify jack connections with jack_lsp/jack_connect (because
they will always be present on any system that has jack) and of course
point to user-friendly tools such as JackPilot, qjackctl, or patchage.
also tell the user how to access jackd error messages.

no votes for implicit magic without being obvious about what's being done.

good example of how not to do magic (no systemd bashing here, plz, it's
just an example!): i use cd ripping tool "asunder" and tell it to log to
/var/log/asunder.log because i suspect hardware failure of a dvdrw
drive. no log ever appears. days later, i look through the system
journal and see that it has incorporated the asunder log messages.
either asunder logs to syslog anyways and hasn't updated its gui to
reflect it (then i don't have a case here), or journald has some magic
to catch any attempt to start a log in /var/log and reroutes it to the
global log. if the latter, then the user-friendly way to do it is to
write a stub /var/log/asunder.log that contains a note as to what has
happened to the log and where the information is to be found. again: no
implicitism without making it obvious what is happening for old people
who still think everything is a file.

i still think the best way to make jack user-friendly is to quickly
educate users how to start a graphical jack config and patching tool,
and then start their app. this is the free software community. unless we
want to make all our hangouts on IRC, mailing lists, and forums
uninhabitable, we MUST NOT DUMB DOWN OUR NEW USERS, and what's worse,
annoy old and experienced ones!
be friendly, yes, by all means. hide the underlying workings from users
and prevent them from understanding them, never.


just my few cents,


Jörn



--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. [phone]

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jörn Nettingsmeier-5]

On 02/01/2016 12:52 PM, Jörn Nettingsmeier wrote:

> * pop open a notice to the effect that no jack server has been found and
> does the user want you to do that for her/him? together with a checkbox
> to not ask again and a notice on how to undo the "don't ask again".
>
> * spawn a jackd server and explain to the user how it guessed what
> configuration to use and how to change that. also point out to the user
> how to see/modify jack connections with jack_lsp/jack_connect (because
> they will always be present on any system that has jack) and of course
> point to user-friendly tools such as JackPilot, qjackctl, or patchage.
> also tell the user how to access jackd error messages.

i guess my point in a nutshell is this: if you invent some
user-friendliness that shields the user from having to manually set up a
key part of their workflow, you are responsible for making sure they are
aware what's being done, and ideally learn how to do it/control it
themselves.
discoverability, discoverability, discoverability.


--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. [phone]

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Kjetil Matheussen-2]

On Mon, Feb 1, 2016 at 1:09 PM, Jörn Nettingsmeier <[hidden email]> wrote:

i guess my point in a nutshell is this: if you invent some user-friendliness that shields the user from having to manually set up a key part of their workflow, you are responsible for making sure they are aware what's being done, and ideally learn how to do it/control it themselves.
discoverability, discoverability, discoverability.

Yes, exactly, and that's one of the points I was trying to make. Starting a jackd process

in the background without the user knowing is not good. Instead - and this is my highly

opinioned opinion - the client should sometimes also be the server, and all the server

options and feedback, should be accessible to the client.

Nothing of importance to the user should be printed to

stdout or stderr, or provided via a string as command line arguments. All communication

should be formally specified, both options for starting the server, and feedback from the

server. The driver programmer should assume that information printed to stdout or

stderr will never be read or understood. And in order for the clients to show/configure

the server part of the client, libjack should provide common GUIs that all

clients may use. This way, you may use Ardour, for instance, alone, but you

may also start the jack server with qjackctl or jackd first if you want to. Ardour will

tell you if it is functioning as the server, or not.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[John Rigg-16]

On Mon, Feb 01, 2016 at 12:52:47PM +0100, Jörn Nettingsmeier wrote:
> i still think the best way to make jack user-friendly is to quickly  
> educate users how to start a graphical jack config and patching tool,  
> and then start their app. this is the free software community. unless we  
> want to make all our hangouts on IRC, mailing lists, and forums  
> uninhabitable, we MUST NOT DUMB DOWN OUR NEW USERS, and what's worse,  
> annoy old and experienced ones!
> be friendly, yes, by all means. hide the underlying workings from users  
> and prevent them from understanding them, never.

Agree 100%. One person's "user friendly" is often the opposite for the more
experienced user. I think the tendency to remove the need for understanding
is quite unhealthy (see Darwin).

John
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jörn Nettingsmeier-5]

On 02/01/2016 01:28 PM, Kjetil Matheussen wrote:
> Instead - and
> this is my highly
> opinioned opinion - the client should sometimes also be the server,

i disagree, most emphatically. the client should never be the server. do
you want to spend ages figuring out whether a jack problem happened with
an in-process server or external server, each time a user cries their
eyes out on IRC? do you want to battle all the conceptual
misunderstandings about how in-process servers are faster, and
out-of-process servers are more robust, and sound warmer? why? what's so
bad about a clean conceptual separation?

> and
> all the server
> options and feedback, should be accessible to the client.

now that is something we can agree on, but that's *completely* orthogonal.

but the way i do it, i open qjackctl and look at the message window.
problem solved. and i guess i can explain that to users far more quickly
than you can implement a new message passing API for jackd.
developer time saved, user understanding improved. two sacred pillars of
the open source culture.


--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. [phone]

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Kjetil Matheussen-2]

On Mon, Feb 1, 2016 at 1:39 PM, Jörn Nettingsmeier <[hidden email]> wrote:

On 02/01/2016 01:28 PM, Kjetil Matheussen wrote:

Instead - and
this is my highly
opinioned opinion - the client should sometimes also be the server,

i disagree, most emphatically. the client should never be the server. do you want to spend ages figuring out whether a jack problem happened with an in-process server or external server, each time a user cries their eyes out on IRC? do you want to battle all the conceptual misunderstandings about how in-process servers are faster, and out-of-process servers are more robust, and sound warmer? why? what's so bad about a clean conceptual separation?

Two reasons:

1. No need to use anything other than Jack. Ardour now has got the option of not using Jack. Shouldn't

have been necessary.

2. It feels like a server configuration protocol will stabilize faster if clients also can function as servers

since more code is using it, not just qjackctl.

and
all the server
options and feedback, should be accessible to the client.

now that is something we can agree on, but that's *completely* orthogonal.

but the way i do it, i open qjackctl and look at the message window. problem solved. and i guess i can explain that to users far more quickly than you can implement a new message passing API for jackd.
developer time saved, user understanding improved. two sacred pillars of the open source culture.

It works, but the more components you glue together, the higher the chance is for something

to fail. For instance didn't the messages window in the windows version of qjackctl show anything

coming from jackd until autumn 2015.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Mon, Feb 1, 2016 at 7:54 AM, Kjetil Matheussen <[hidden email]> wrote:

Two reasons:

1. No need to use anything other than Jack. Ardour now has got the option of not using Jack. Shouldn't

have been necessary.

if you believe this, then clearly you do not understand why we did this.

 

2. It feels like a server configuration protocol will stabilize faster if clients also can function as servers

since more code is using it, not just qjackctl.

the server configuration protocol has existed for nearly 8 years. almost nobody has chosen to use it, for anything at all. jackdbus is more or less its only use case.

 

It works, but the more components you glue together, the higher the chance is for something

to fail. For instance didn't the messages window in the windows version of qjackctl show anything

coming from jackd until autumn 2015.

that has to do with windows and qjackctl, not with jackd.

 

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Kjetil Matheussen-2]

On Mon, Feb 1, 2016 at 3:02 PM, Paul Davis <[hidden email]> wrote:

 

2. It feels like a server configuration protocol will stabilize faster if clients also can function as servers

since more code is using it, not just qjackctl.

the server configuration protocol has existed for nearly 8 years. almost nobody has chosen to use it, for anything at all. jackdbus is more or less its only use case.

I was thinking of a new configuration protocol where any libjack client can function as server.

 

 

It works, but the more components you glue together, the higher the chance is for something

to fail. For instance didn't the messages window in the windows version of qjackctl show anything

coming from jackd until autumn 2015.

that has to do with windows and qjackctl, not with jackd.

 

But it illustrates how flaky the system is when a bug like this can exist for 10 years.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[David Nielson-2]

On 02/01/2016 08:31 AM, Kjetil Matheussen wrote:
>
> I was thinking of a new configuration protocol where any libjack client
> can function as server.
>

:|

why would you do that?

David Nielson


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Kjetil Matheussen-2]

On Mon, Feb 1, 2016 at 3:45 PM, David Nielson <[hidden email]> wrote:

On 02/01/2016 08:31 AM, Kjetil Matheussen wrote:
>
> I was thinking of a new configuration protocol where any libjack client
> can function as server.
>

:|

why would you do that?

Well, one reason is to force forward a formally defined configuration protocol which is actually used.

qjackctl would be forced to use this configuration, and the same with jackd. No more flaky

use of sending around very informally specified strings via stdout and stdin as a communication protocol.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[sqweek]

On 1 February 2016 at 22:31, Kjetil Matheussen <[hidden email]> wrote:

>>> to fail. For instance didn't the messages window in the windows version
>>> of qjackctl show anything
>>> coming from jackd until autumn 2015.
>>
>> that has to do with windows and qjackctl, not with jackd.
>
> But it illustrates how flaky the system is when a bug like this can exist
> for 10 years.

No, a 10 year old bug illustrates nothing but the nature of open
source. For a bug to be fixed it must (a) be encountered (b) be
reported and (c) receive developer attention. (a) & (b) is extremely
hard for qjackctl on win32 because the majority of the userbase is on
a different platform. Hats off to yourself for stepping up to fill (c)
and giving win32 some much needed attention, but this doesn't make
jackd "flaky".

Your proposal doesn't make sense in general. It's narrow minded and
very focused on the GUI application use-case. Most of the JACK clients
I run have no GUI at all. If they are the first client to run and you
still want to configure JACK's options via a GUI, you *need* to spawn
a separate process.

Anyway, a separate process makes the whole system *more* robust, not
more flaky. If the jack server is running in the same address space as
a client, then an error in that client (segfault/buffer overflow/etc)
can bring down the entire audio system.

It sounds like the existing configuration mechanism provided by jackd
enables you to do what you want already (ie. running ~/.jackdrc). You
can do literally whatever you want in this script. You don't have to
run jackd directly, you can write a GUI frontend that lets you
configure options before launching jackd and make ~/.jackdrc launch
*that*.

The best part about this is that it just works with no change to
jackd, no change to libjack, and no change to any clients. This is
UNIX philosophy. We have simple tools and we glue them together. And
the result is beautiful.



Well, sometimes :)

While I'm here let me throw in a thanks for jack. It's a beacon of
simplicity in the mess that is linux audio. If it wasn't for bluetooth
I would still be using it exclusively rather than being stuck with
pulseaudio :)

-sqweek
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Thomas Brand]

On Mon, February 1, 2016 15:49, Kjetil Matheussen wrote:

> On Mon, Feb 1, 2016 at 3:45 PM, David Nielson <[hidden email]>
> wrote:
>
>>
>> On 02/01/2016 08:31 AM, Kjetil Matheussen wrote:
>>
>>>
>>> I was thinking of a new configuration protocol where any libjack
>>> client can function as server.
>>>
>>
>> :|
>>
>>
>> why would you do that?
>>
>> Well, one reason is to force forward a formally defined configuration
>>
> protocol which is actually used. qjackctl would be forced to use this
> configuration, and the same with jackd. No more flaky use of sending around
> very informally specified strings via stdout and stdin as a communication
> protocol.

with all respect, the client/server model of jack seems well designed.

we could argue about the use of clients autostarting the server (with
semi-default and semi-custom settings in any jackdrc file), since if the
server doesn't run, nobody has started it explicitely thus the clients
can't work. if there are multiple choices of audio device to use, that is
HDMI, intel analog, external attached USB, firewire ..
i think the autostart feature is one of the pitfalls that made users see
many of the "could not start" messages. plus that there is some problems
with multiple sound servers wanting exclusive access to the device. other
issues are not mainly jack's problem, which is configuration of the system
(permit RT to to user, possibly use lowlateny kernel) and badly programmed
clients that behave one way or the other and can affect the server
operation as a whole. which again is a side-effect of this open ecosystem.
if i run a system with just jack, alsa, ffado and known-to-work clients
installed it works better than anything else.

building the gui into the server is surely not a good idea.

a recent "stock" install of a selection of jack tools showed no major
issues. it's a really mature ecosystem. if it doesn't change all the time,
this can be a sign of "close to finished" that again is what makes lasting
APIs useful. look at VST or any out-dated standards. one aspect these
plugins are still in use is that the API didn't change much.
compare it with PI, it didn't change much, is used in many formulas and
saying PI is dead is as funny as saying JACK is dead :)
greetings
tom


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Kjetil Matheussen-2]

On Mon, Feb 1, 2016 at 4:39 PM, sqweek <[hidden email]> wrote:

On 1 February 2016 at 22:31, Kjetil Matheussen <[hidden email]> wrote:

>>> to fail. For instance didn't the messages window in the windows version
>>> of qjackctl show anything
>>> coming from jackd until autumn 2015.
>>
>> that has to do with windows and qjackctl, not with jackd.
>
> But it illustrates how flaky the system is when a bug like this can exist
> for 10 years.

No, a 10 year old bug illustrates nothing but the nature of open
source. For a bug to be fixed it must (a) be encountered (b) be
reported and (c) receive developer attention. (a) & (b) is extremely
hard for qjackctl on win32 because the majority of the userbase is on
a different platform. Hats off to yourself for stepping up to fill (c)
and giving win32 some much needed attention, but this doesn't make
jackd "flaky".

I understand why things are like they are. I'm not claiming anyone has done

a bad job. Absolutely not. I just point out that things can be better. Had there been

a libjackserver library, where the server itself had been included,

qjackctl could have linked to that library instead of starting a process

and do very informal and flaky communication between the server

and the GUI.

(Oh, and regarding the qjackctl bug. I didn't only do (c), I also fixed

the bug itself)

 

Your proposal doesn't make sense in general. It's narrow minded and
very focused on the GUI application use-case.

No, it's not. I'm proposing to put the jack server into a library, preferably

libjack. jackd wouldn't stop to exist because of that.

Anyway, a separate process makes the whole system *more* robust, not
more flaky. If the jack server is running in the same address space as
a client, then an error in that client (segfault/buffer overflow/etc)
can bring down the entire audio system.

But I'm not proposing to remove jackd. If you want to continue using

jackd, you can.

 

It sounds like the existing configuration mechanism provided by jackd
enables you to do what you want already (ie. running ~/.jackdrc). You
can do literally whatever you want in this script. You don't have to
run jackd directly, you can write a GUI frontend that lets you
configure options before launching jackd and make ~/.jackdrc launch
*that*. 

That's all good. But as I've pointed out, there's no proper way to find

out what's really happening. libjack should have a 'char *jack_info()' function

that clients can display, as a minimum.

 

 

The best part about this is that it just works with no change to
jackd, no change to libjack, and no change to any clients. This is
UNIX philosophy. We have simple tools and we glue them together. And
the result is beautiful.

And I'm proposing to extend that thought further by putting the server part

of jackd into a library.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jörn Nettingsmeier-5]

On 02/01/2016 04:43 PM, [hidden email] wrote:

> compare it with PI, it didn't change much, is used in many formulas and
> saying PI is dead is as funny as saying JACK is dead :)
> greetings
> tom

well, there is pi v2:
https://en.wikipedia.org/wiki/Turn_%28geometry%29#Tau_proposal

(sorry, couldn't resist)


--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. [phone]

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Thomas Brand]

On Mon, February 1, 2016 16:53, Jörn Nettingsmeier wrote:

> On 02/01/2016 04:43 PM, [hidden email] wrote:
>
>
>> compare it with PI, it didn't change much, is used in many formulas and
>>  saying PI is dead is as funny as saying JACK is dead :) greetings tom
>
> well, there is pi v2:
> https://en.wikipedia.org/wiki/Turn_%28geometry%29#Tau_proposal
>
>
> (sorry, couldn't resist)
>
>

:)
this is just a question of mapping (/me thinks "..-compat" ;)


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Mon, Feb 1, 2016 at 9:31 AM, Kjetil Matheussen <[hidden email]> wrote:

On Mon, Feb 1, 2016 at 3:02 PM, Paul Davis <[hidden email]> wrote:

 

2. It feels like a server configuration protocol will stabilize faster if clients also can function as servers

since more code is using it, not just qjackctl.

the server configuration protocol has existed for nearly 8 years. almost nobody has chosen to use it, for anything at all. jackdbus is more or less its only use case.

I was thinking of a new configuration protocol where any libjack client can function as server.

This already exists. I am a little shocked that you don't know this.

 

 

But it illustrates how flaky the system is when a bug like this can exist for 10 years.

No, it does not. It illustrates how shallow and low energy the development "team" for JACK is, especially on Windows.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 1 févr. 2016 à 16:53, Kjetil Matheussen <[hidden email]> a écrit :

>
>
> On Mon, Feb 1, 2016 at 4:39 PM, sqweek <[hidden email]> wrote:
> On 1 February 2016 at 22:31, Kjetil Matheussen <[hidden email]> wrote:
>
>  
>  
> The best part about this is that it just works with no change to
> jackd, no change to libjack, and no change to any clients. This is
> UNIX philosophy. We have simple tools and we glue them together. And
> the result is beautiful.
>
> And I'm proposing to extend that thought further by putting the server part
> of jackd into a library.

GRRR :  libjackserver has been there since 2007 ? 2008  ? and jackd is (since that time….) an executable that uses the so-control API to start and control the server, and is *linked* with libjackserver…

Stéphane  

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Mon, Feb 1, 2016 at 11:07 AM, Stéphane Letz <[hidden email]> wrote:

> And I'm proposing to extend that thought further by putting the server part
> of jackd into a library.

GRRR :  libjackserver has been there since 2007 ? 2008  ? and jackd is (since that time….) an executable that uses the so-control API to start and control the server, and is *linked* with libjackserver…

I think that this deserves more than just a "GRRRR" Stephane :)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Kjetil Matheussen-2]

On Mon, Feb 1, 2016 at 5:07 PM, Stéphane Letz <[hidden email]> wrote:

Le 1 févr. 2016 à 16:53, Kjetil Matheussen <[hidden email]> a écrit :

>
>
> On Mon, Feb 1, 2016 at 4:39 PM, sqweek <[hidden email]> wrote:
> On 1 February 2016 at 22:31, Kjetil Matheussen <[hidden email]> wrote:
>
>
>
> The best part about this is that it just works with no change to
> jackd, no change to libjack, and no change to any clients. This is
> UNIX philosophy. We have simple tools and we glue them together. And
> the result is beautiful.
>
> And I'm proposing to extend that thought further by putting the server part
> of jackd into a library.

GRRR :  libjackserver has been there since 2007 ? 2008  ? and jackd is (since that time….) an executable that uses the so-control API to start and control the server, and is *linked* with libjackserver…

 

Oh, right. That's what I thought too, but I must have misunderstood what Paul

meant by "libjackserver isn't what you think it is". Anyway, good to know.

Now we only need to add gui functions to libjackserver (i.e. pull out stuff from

qjackctl into a new executable which can only be started by libjackserver, and communicate

with that executable via sockets), move libjackserver into libjack,

and let jack_client_open start jack via libjackserver.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Mon, Feb 1, 2016 at 11:23 AM, Kjetil Matheussen <[hidden email]> wrote:

Oh, right. That's what I thought too, but I must have misunderstood what Paul

meant by "libjackserver isn't what you think it is". Anyway, good to know.

Now we only need to add gui functions to libjackserver (i.e. pull out stuff from

qjackctl into a new executable which can only be started by libjackserver, and communicate

with that executable via sockets), move libjackserver into libjack,

and let jack_client_open start jack via libjackserver.

GUI functions? they'd have to be in a separate process. so you still have to write a different executable, which means you're basically reinventing qjackctl but just fork+exec'ing it from a client rather than using jack auto-start features, plus making the real client wait until the server appears (which could be seconds, minutes or hours later).

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org