1 Feb
2016
1 Feb
'16
4:52 a.m.
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. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
1 Feb
1 Feb
5:09 a.m.
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. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
5:28 a.m.
On Mon, Feb 1, 2016 at 1:09 PM, Jörn Nettingsmeier <
nettings(a)stackingdwarves.net> 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.
5:40 a.m.
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. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
5:54 a.m.
On Mon, Feb 1, 2016 at 1:39 PM, Jörn Nettingsmeier <
nettings(a)stackingdwarves.net> wrote:
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.
On 02/01/2016 01:28 PM, Kjetil Matheussen 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.
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
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?
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 
7:02 a.m.
On Mon, Feb 1, 2016 at 7:54 AM, Kjetil Matheussen <k.s.matheussen(a)gmail.com>
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.
7:31 a.m.
On Mon, Feb 1, 2016 at 3:02 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
I was thinking of a new configuration protocol where any libjack client can
function as server.
But it illustrates how flaky the system is when a bug like this can exist
for 10 years.
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.
7:49 a.m.
On Mon, Feb 1, 2016 at 3:45 PM, David Nielson <david(a)naptastic.com> wrote:
On 02/01/2016 08:31 AM, Kjetil Matheussen wrote:
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.
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 
8:43 a.m.
On Mon, February 1, 2016 15:49, Kjetil Matheussen wrote:
On Mon, Feb 1, 2016 at 3:45 PM, David Nielson
<david(a)naptastic.com>
wrote:
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
On 02/01/2016 08:31 AM, Kjetil Matheussen wrote:
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.
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
8:53 a.m.
On 02/01/2016 04:43 PM, tom(a)trellis.ch 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. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
8:58 a.m.
On Mon, February 1, 2016 16:53, Jörn Nettingsmeier wrote:
On 02/01/2016 04:43 PM, tom(a)trellis.ch wrote:
:)
this is just a question of mapping (/me thinks "..-compat" ;)
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)
8:39 a.m.
On 1 February 2016 at 22:31, Kjetil Matheussen <k.s.matheussen(a)gmail.com> wrote:
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
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.
8:53 a.m.
On Mon, Feb 1, 2016 at 4:39 PM, sqweek <sqweek(a)gmail.com> wrote:
The best part about this is that it just works with no change to
On 1 February 2016 at 22:31, Kjetil Matheussen
<k.s.matheussen(a)gmail.com>
wrote:
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)
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. 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.
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.
9:07 a.m.
Le 1 févr. 2016 à 16:53, Kjetil Matheussen <k.s.matheussen(a)gmail.com> a écrit :
On Mon, Feb 1, 2016 at 4:39 PM, sqweek <sqweek(a)gmail.com> wrote:
On 1 February 2016 at 22:31, Kjetil Matheussen <k.s.matheussen(a)gmail.com> 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
9:08 a.m.
On Mon, Feb 1, 2016 at 11:07 AM, Stéphane Letz <letz(a)grame.fr> wrote:
I think that this deserves more than just a "GRRRR" Stephane :)
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…
9:23 a.m.
On Mon, Feb 1, 2016 at 5:07 PM, Stéphane Letz <letz(a)grame.fr> wrote:
Le 1 févr. 2016 à 16:53, Kjetil Matheussen <k.s.matheussen(a)gmail.com> a
écrit :
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.
On Mon, Feb 1, 2016 at 4:39 PM, sqweek <sqweek(a)gmail.com> wrote:
On 1 February 2016 at 22:31, Kjetil Matheussen <k.s.matheussen(a)gmail.com>
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…
9:25 a.m.
On Mon, Feb 1, 2016 at 11:23 AM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
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).
<http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org>
9:30 a.m.
On Mon, February 1, 2016 17:23, Kjetil Matheussen wrote:
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.
the outcome would be that if a client starts and no jack server was
started, a gui pops up? that would be nice and i think it could be done
via a hook jack would offer ("pre-autostartup user interaction") that's
separated from the server. the details are not fully clear but the outcome
of a dialogue that asks for device selection and params if server not
started i think is attractive in gui environments.
cheers
tom
9:32 a.m.
On Mon, Feb 1, 2016 at 11:23 AM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
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.
and of course, none of this works if (a) the client says "do not start the
server" (b) the client doesn't interact directly with JACK at all (as in
the case mentioned by Michael, using a non-JACK application (c) in a
headless environment.
9:41 a.m.
On Mon, Feb 1, 2016 at 5:25 PM, John Rigg <j(a)jrigg.co.uk> wrote:
On Mon, Feb 01, 2016 at 05:23:17PM +0100, Kjetil Matheussen wrote:
to
configure jack, where the communication between libjack and the gui
happens by sockets, not by stdout+stdin. This will not make libjack
link with a graphics library, and it will most likely not increase the
size of libjack, and it will not make jackd disappear.
Now we only need to add gui functions to
libjackserver
Please, no! As has been pointed out, not all jack clients are GUI based,
and many of us prefer to start jackd from the command line or a script.
I'm suggesting to add gui functions which are calling an external program
9:47 a.m.
On Mon, Feb 1, 2016 at 11:41 AM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
wrote:
I'm suggesting to add gui functions which are calling an external program
to configure jack, where the communication between libjack and the gui
happens by sockets, not by stdout+stdin.
this already exists. your issue with it is the communication is currently
asymmetric: there is a structured protocol to configure and start the
server, but not in the reverse direction. you want errors and status
returned as well. and you want a structured protocol for this direction,
rather than semi-random line-oriented text.
This will not make libjack
link with a graphics library, and it will most likely not increase the
size of libjack, and it will not make jackd disappear.
so how will an abritrary client become "the server" ?
it is just amazing to me, given all the other useful things that JACK could
be made to do, that anyone is talking about the mechanics of starting it.
10:01 a.m.
On Mon, February 1, 2016 17:47, Paul Davis wrote:
it is just amazing to me, given all the other useful
things that JACK
could be made to do, that anyone is talking about the mechanics of
starting it.
apropos startup: can a client today start up a dummy server with given
properties? for a temporary non-default/private ecosystem i.e. for
freewheeling without interrupting the default jack that is possibly
attached to the hardware.
10:12 a.m.
On Mon, Feb 1, 2016 at 12:01 PM, <tom(a)trellis.ch> wrote:
On Mon, February 1, 2016 17:47, Paul Davis wrote:
Configuring a given JACK server is always a potentially complex operation,
given the number of possible parameters for both the server and the backend.
Any client can start a server with any parameters. But for that to be
useful to the user, it probably has to present the options to the user and
gather their choices; That isn't trivial, which is partly why almost no
clients bother to even try this (Ardour is one of the few non-control
applications that does, and even it imposes drastic limitations on options
the user can select from).
it is just amazing to me, given all the other
useful things that JACK
could be made to do, that anyone is talking about the mechanics of
starting it.
apropos startup: can a client today start up a dummy server with given
properties? for a temporary non-default/private ecosystem i.e. for
freewheeling without interrupting the default jack that is possibly
attached to the hardware.
10:18 a.m.
On Mon, February 1, 2016 18:12, Paul Davis wrote:
On Mon, Feb 1, 2016 at 12:01 PM,
<tom(a)trellis.ch> wrote:
to put in other words i wondered if a client can ask to "autostart" a
temporary dummy server with only a few arguments easily code-wise
(assuming *any* jack has a dummy backend built-in) instead of relying on
the ~/.jackrc file.
the other non-dummy cases are more dialogue-demanding, no question.
On Mon, February 1, 2016 17:47, Paul Davis
wrote:
Configuring a given JACK server is always a potentially complex
operation, given the number of possible parameters for both the server and
the backend.
Any client can start a server with any parameters. But for that to be
useful to the user, it probably has to present the options to the user and
gather their choices; That isn't trivial, which is partly why almost no
clients bother to even try this (Ardour is one of the few non-control
applications that does, and even it imposes drastic limitations on
options the user can select from).
it is just amazing to me, given all the other
useful things that JACK
could be made to do, that anyone is talking about the mechanics of
starting it.
apropos startup: can a client today start up a dummy server with given
properties? for a temporary non-default/private ecosystem i.e. for
freewheeling without interrupting the default jack that is possibly
attached to the hardware.
10:26 a.m.
On Mon, Feb 1, 2016 at 12:18 PM, <tom(a)trellis.ch> wrote:
to put in other words i wondered if a client can ask to "autostart" a
temporary dummy server with only a few arguments easily code-wise
(assuming *any* jack has a dummy backend built-in) instead of relying on
the ~/.jackrc file.
the other non-dummy cases are more dialogue-demanding, no question.
The dummy driver still has a good size selection of parameters. And such a
startup also offers all possible server parameters too. Starting the dummy
is not really notably easier than starting any other backend.
2 Feb
2 Feb
8:17 a.m.
On 01.02.2016 18:18, tom(a)trellis.ch wrote:
to put in other words i wondered if a client can ask
to "autostart" a
temporary dummy server with only a few arguments easily code-wise
(assuming *any* jack has a dummy backend built-in) instead of relying
on the ~/.jackrc file. the other non-dummy cases are more
dialogue-demanding, no question.
Actually, yes.
See https://github.com/jackaudio/jack1/blob/master/libjack/client.c#L868
You can create your own jackdrc file and set the env var 'JACK_RC_FILE'
to that before calling jack_client_open.
That way if jack is not running yet, the jackd command will be read from
that file instead of the default ~/.jackdrc.
2:33 p.m.
On Tue, February 2, 2016 16:17, Filipe Coelho wrote:
On 01.02.2016 18:18, tom(a)trellis.ch wrote:
this is a nice hack, i will try :)
grep -r JACK_RC_FILE in jack2 source directory didn't reveal anything
while in jack1 did so this must be a jack1 speciality.
thanks for the hint!
cheers
tom
to put in other words i wondered if a client can
ask to "autostart" a
temporary dummy server with only a few arguments easily code-wise
(assuming *any* jack has a dummy backend built-in) instead of relying
on the ~/.jackrc file. the other non-dummy cases are more
dialogue-demanding, no question.
Actually, yes.
See https://github.com/jackaudio/jack1/blob/master/libjack/client.c#L868
You can create your own jackdrc file and set the env var 'JACK_RC_FILE'
to that before calling jack_client_open. That way if jack is not running
yet, the jackd command will be read from that file instead of the default
~/.jackdrc.
3:39 p.m.
On 02/02/2016 09:33 PM, tom(a)trellis.ch wrote:
On Tue, February 2, 2016 16:17, Filipe Coelho wrote:
also, rather exclusive for the brave:
http://www.rncbc.org/drupal/node/658
(scroll down and start reading from where the qjackctl-auto-start-hack
is whispered after "the lines that follow...";))
it has been working for me, for ages now
cheers
--
rncbc aka. Rui Nuno Capela
On 01.02.2016 18:18, tom(a)trellis.ch wrote:
You can create your own jackdrc file and set the env var 'JACK_RC_FILE'
to that before calling jack_client_open. That way if jack is not running
yet, the jackd command will be read from that file instead of the default
~/.jackdrc.
this is a nice hack, i will try :)
grep -r JACK_RC_FILE in jack2 source directory didn't reveal anything
while in jack1 did so this must be a jack1 speciality.
thanks for the hint!
cheers
tom
4:51 p.m.
On 02/02/16 16:39, Rui Nuno Capela wrote:
also, rather exclusive for the brave:
http://www.rncbc.org/drupal/node/658
(scroll down and start reading from where the qjackctl-auto-start-hack
is whispered after "the lines that follow...";))
it has been working for me, for ages now
cheers
(maybe this is unrelated but) I compile jack2 from source on Debian Sid.
A few days ago, I installed the pulseaudio JACK source/sink package from
Debian, and added these lines to /etc/pulse/default.pa, in the "load
drivers statically" section:
load-module module-jack-sink
load-module module-jack-source
Now JACK runs whenever the computer is running, and all inputs and
outputs are mapped magically. This does result in "you've got mail"
coming out the PA system, so it's not for everyone, but since I've got
24 ins and outs, I can map things the way I want...
...when did things get this easy? And powerful?
David
3 Feb
3 Feb
5:27 a.m.
On 2 February 2016 at 23:51, David Nielson <david(a)naptastic.com> wrote:
On 02/02/16 16:39, Rui Nuno Capela wrote:
Have been using that trick for a few years now. You can even fix the
system notifications too, if there's a separate sound interface you
want them to come out of, just use pavucontrol and set the output for
system notifications to a device other tha the jack sink. (Honestly, I
always turn them off anyway.) It's really nice to be able to do it,
because you can feed sounds from things within pulseaudio into your
workflow (e.g. youtube into DAW).
Many thanks to Paul and all the others who have worked on Jack (and
Rui for the very useful qjackctl). I think it's currently suffering
from the problem that it does what it's supposed to, which tends to
make projects look like they've stalled.
(If I had one wishlist item, it would be multiple sources, but I
realise there are significant technical challenges there. Having
separate source and output is useful though.)
--
imalone
http://ibmalone.blogspot.co.uk
also, rather exclusive for the brave:
http://www.rncbc.org/drupal/node/658
(scroll down and start reading from where the qjackctl-auto-start-hack is
whispered after "the lines that follow...";))
it has been working for me, for ages now
cheers
(maybe this is unrelated but) I compile jack2 from source on Debian Sid. A
few days ago, I installed the pulseaudio JACK source/sink package from
Debian, and added these lines to /etc/pulse/default.pa, in the "load drivers
statically" section:
load-module module-jack-sink
load-module module-jack-source
Now JACK runs whenever the computer is running, and all inputs and outputs
are mapped magically. This does result in "you've got mail" coming out the
PA system, so it's not for everyone, but since I've got 24 ins and outs, I
can map things the way I want...
...when did things get this easy? And powerful?
5:45 a.m.
On Wed, Feb 3, 2016 at 7:27 AM, Ian Malone <ibmalone(a)gmail.com> wrote:
(If I had one wishlist item, it would be multiple sources, but I
realise there are significant technical challenges there. Having
separate source and output is useful though.)
Sigh.
This has been part of Jack1 on Linux for a couple of years, and part of
Jack2 on other platforms for much longer.
For Jack1, the -A or -I options provide a simple or complex (respectively)
to add arbitrary input or output devices to the server at startup time.
If you're willing to add them later, then on Linux, zita_a2j and zita_j2a
do a fine job.
--
imalone
http://ibmalone.blogspot.co.uk
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
6:36 a.m.
On 3 February 2016 at 12:45, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Wed, Feb 3, 2016 at 7:27 AM, Ian Malone <ibmalone(a)gmail.com> wrote:
Thanks, never saw this documented anywhere. zita_ajbridge looks very useful too.
--
imalone
http://ibmalone.blogspot.co.uk
(If I had one wishlist item, it would be multiple sources, but I
realise there are significant technical challenges there. Having
separate source and output is useful though.)
Sigh.
This has been part of Jack1 on Linux for a couple of years, and part of
Jack2 on other platforms for much longer.
For Jack1, the -A or -I options provide a simple or complex (respectively)
to add arbitrary input or output devices to the server at startup time.
If you're willing to add them later, then on Linux, zita_a2j and zita_j2a do
a fine job.
11:14 a.m.
On Wed, 3 Feb 2016 13:36:13 +0000
Ian Malone <ibmalone(a)gmail.com> wrote:
On 3 February 2016 at 12:45, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
It's in the man page (at least for jack1). zita-n2jbridge is also a
very useful utility!
--
Joakim
For Jack1, the -A or -I options provide a simple or complex
(respectively) to add arbitrary input or output devices to the
server at startup time.
Thanks, never saw this documented anywhere. zita_ajbridge looks very
useful too.
11:59 a.m.
On Wed, February 3, 2016 19:14, Joakim Hernberg wrote:
On Wed, 3 Feb 2016 13:36:13 +0000
Ian Malone <ibmalone(a)gmail.com> wrote:
it's useful and maybe underestimated. it needs a gui :)
there was jack diplomat at one time and now zita-n2j/j2n bridge does it
right.
On 3 February 2016 at 12:45, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
It's in the man page (at least for jack1). zita-n2jbridge is also a
very useful utility!
For Jack1, the -A or -I options provide a simple or complex
(respectively) to add arbitrary input or output devices to the
server at startup time.
Thanks, never saw this documented anywhere. zita_ajbridge looks very
useful too.
1:24 p.m.
On 02/03/2016 07:59 PM, tom(a)trellis.ch wrote:
On Wed, February 3, 2016 19:14, Joakim Hernberg
wrote:
It's in the man page (at least for jack1). zita-n2jbridge is also a
very useful utility!
it's useful and maybe underestimated. it needs a gui :)
there was jack diplomat at one time and now zita-n2j/j2n bridge does it
right.
especially since you can tell the zita bridge that the two devices are
externally synced, and then it will not do any resampling (which saves
cpu and might help people relax who are worried about resampling
artefacts, not that it has any).
--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT
http://stackingdwarves.net
For Jack1, the -A or -I options provide a simple or
complex
(respectively) to add arbitrary input or output devices to the
server at startup time.
Thanks, never saw this documented anywhere. zita_ajbridge looks very
useful too. 
1:36 p.m.
On Wed, 3 Feb 2016 21:24:01 +0100, Jörn Nettingsmeier wrote:
especially since you can tell the zita bridge that the
two devices are
externally synced, and then it will not do any resampling (which saves
cpu and might help people relax who are worried about resampling
artefacts, not that it has any).
:)
Some people didn't know it ;). IIRC on LAU and LAD it was always
mentioned in a context with resampling.
3:15 a.m.
On Tue, February 2, 2016 23:39, Rui Nuno Capela wrote:
On 02/02/2016 09:33 PM, tom(a)trellis.ch wrote:
i see, interesting. especially the chmod a-w part ;)
On Tue, February 2, 2016 16:17, Filipe Coelho
wrote:
also, rather exclusive for the brave: http://www.rncbc.org/drupal/node/658
(scroll down and start reading from where the qjackctl-auto-start-hack
is whispered after "the lines that follow...";)) it has been working for
me, for ages now
On 01.02.2016 18:18, tom(a)trellis.ch wrote:
You can create your own jackdrc file and set the env var
'JACK_RC_FILE'
to that before calling jack_client_open. That way if jack is not
running yet, the jackd command will be read from that file instead of
the default ~/.jackdrc.
this is a nice hack, i will try :) grep -r JACK_RC_FILE in jack2 source
directory didn't reveal anything while in jack1 did so this must be a
jack1 speciality. thanks for the hint! cheers tom
1 Feb
1 Feb
9:30 a.m.
On 1 February 2016 at 23:53, Kjetil Matheussen <k.s.matheussen(a)gmail.com> wrote:
Yes, that is what I was trying to credit you for. Apologies if that
was unclear, great job! :)
In a different mail you wrote:
(c) receive developer attention.
(Oh, and regarding the qjackctl bug. I didn't only do (c), I also fixed
the bug itself) and communicate with that executable via sockets
https://en.wikipedia.org/wiki/9P_(protocol) ?
^_^
-sqweek
1:07 p.m.
On 02/01/2016 03:53 PM, Kjetil Matheussen wrote:
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)
let me chime in, probably way out of context, but there it goes...
for qjackctl's sake, fwiw.
1) qjackctl was and still is a gui for jackd as it was back on 2003;
2) its primary developer (me) is stuck to the original jackd code base,
that means JACK1;
3) as in a bad lava-flow anti-pattern, jackdmp, win32, jackdbus and what
else, has been glued, as clay thrown to a wall, so to speak, to qjackctl
code base;
4) the original author (me) can't, won't, never will perhaps, test and
ensure quality of all and/or any of those sti(n)cky code that has been
added over a dozen years that have been passed by, any/all but the JACK1
related code, tbh.
5) all that said meaning that qjackctl is NON SUPPORTED software
upstream (me) as far as any other platform BUT Linux--and even there,
JACK2 might suffer more or less from this stance, so sorry.
now please,
don't ever take this lousy piece of junk of software as qjackctl is to
issue an injunction against JACK (1 or 2), please, please and...
signing off.
--
rncbc aka. Rui Nuno Capela
2:38 p.m.
On Mon, 1 Feb 2016 20:07:32 +0000
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
don't ever take this lousy piece of junk of
software as qjackctl is
to issue an injunction against JACK (1 or 2), please, please and...
Despite the above, thanks for the software!
And could we please have a rational discussion about the JACK
ecosystem..
--
Joakim
11:21 p.m.
On Mon, 1 Feb 2016 22:37:53 +0100
Joakim Hernberg <jhernberg(a)alchemy.lu> wrote:
On Mon, 1 Feb 2016 20:07:32 +0000
Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
Heh, rereading the above I realize that I need to make clear that it
wasn't directed at you Rui, it was meant in general.
--
Joakim
don't ever take this lousy piece of junk of
software as qjackctl is
to issue an injunction against JACK (1 or 2), please, please
and...
Despite the above, thanks for the software!
And could we please have a rational discussion about the JACK
ecosystem..
9:06 a.m.
On Mon, Feb 1, 2016 at 9:31 AM, Kjetil Matheussen <k.s.matheussen(a)gmail.com>
wrote:
On Mon, Feb 1, 2016 at 3:02 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
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.
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.
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.
5:29 a.m.
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
3015
days inactive
3017
days old
jackaudio@lists.linuxaudio.org
44 comments
13 participants
participants (13)
-
David Nielson -
Filipe Coelho -
Ian Malone -
Joakim Hernberg -
John Rigg -
Jörn Nettingsmeier -
Kjetil Matheussen -
Paul Davis -
Ralf Mardorf -
Rui Nuno Capela -
sqweek -
Stéphane Letz -
tom＠trellis.ch