23 Mar
2009
23 Mar
'09
7:14 p.m.
nescivi:
On Monday 23 March 2009 14:58:38 Kjetil S. Matheussen
wrote:
Letting jack autoconnect doesn't prevent applications from
setting up a custom connection system, so the above
suggestion is beside my point, and it doesn't address the
problems I was addressing either.
The problem with jack is that application
writers simply don't bother to do all the work required
to handle configurable connection handling,
and instead they just autoconnect to the physical outputs.
If jack had autoconnected by default, we wouldn't have
had this problem.
Without that, the other things I said would have
been incredibly stupid.
I don't think JACK should be complicated by defining autoconnect
mechanisms in
there.
Applications should provide the option and configuration for it.
I think the proposals given for the app to ask upon first startup (either
via
a GUI if the app has a graphical interface, or through command line
interface
if not) to the user how you want to configure the behaviour is the
clearest
way.
The configuration dialog can suggest the first hardware ports by default,
if
that is the expected most common user case.
That way the user is aware that he can configure it, and can adapt the
program
to her needs. i do agree that it would be good to define some
"system aliases" so that
it was possible to reliably and controllably discover *which* physical
ports to connect to if autoconnect is going to be used.
That sounds too complicated. Why not just add a command line option for
jackd for selecting which client to autoconnect to? 
23 Mar
23 Mar
7:33 p.m.
New subject: why shouldn't clients autoconnect to jack
Hiho,
On Monday 23 March 2009 18:14:10 Kjetil S. Matheussen wrote:
Hmm...
I'm not sure what prompted the discussion.
But I think at the moment we have the situation, where there are apps that do
an automatic connection to jack's system output ports.
And not everyone likes this, for various reasons, including possible damage to
hardware.
Even if we add a command line switch now in JACK whether or not to
autoconnect, app writers still need to change their programs, to not make the
connection, on startup, and let JACK handle it instead.
(Since JACK cannot distinguish between whether an app is doing autoconnection
or executing a user initiated connection).
Now, thinking about it again, I agree that maybe not every app writer wants to
go through the pains of making a complicated dialog for configuration; this
may be especially complex if the graphical interface is a wrapper around some
command line program.
So maybe a middle ground would be to add a API function to JACK that says:
request_client_autoconnect
or something like that...
Where JACK can then look for a jack_autoconfig file which has a default entry
for apps that ask for autoconnect, and maybe can be extended with entries by
client name.
Users can then use that file to configure their desired behaviour, or even
turn off autoconnect alltogether, by leaving the default ports empty.
This kind of thing would only require minimal changes in the source code of
many apps (removing the explicit connection commands, and replacing them with
the request to autoconnect), some additions to JACK's API documentation,
including the guidelines on how to do it properly (either ask the user in a
first time startup configuration dialog (advanced version), or rely on the
JACK autoconnect config file (basic version)).
Anyway, just my 2c.
sincerely,
Marije
On Monday 23
March 2009 14:58:38 Kjetil S. Matheussen wrote:
Letting jack autoconnect doesn't prevent applications from
setting up a custom connection system, so the above
suggestion is beside my point, and it doesn't address the
problems I was addressing either.
The problem with jack is that application
writers simply don't bother to do all the work required
to handle configurable connection handling,
and instead they just autoconnect to the physical outputs.
If jack had autoconnected by default, we wouldn't have
had this problem. Without that, the other things I said would have
been incredibly
stupid.
I don't think JACK should be complicated by defining autoconnect
mechanisms in
there.
Applications should provide the option and configuration for it.
I think the proposals given for the app to ask upon first startup (either
via
a GUI if the app has a graphical interface, or through command line
interface
if not) to the user how you want to configure the behaviour is the
clearest
way.
The configuration dialog can suggest the first hardware ports by default,
if
that is the expected most common user case.
That way the user is aware that he can configure it, and can adapt the
program
to her needs. i do agree that it would be good to define some
"system aliases" so
that it was possible to reliably and controllably discover *which*
physical ports to connect to if autoconnect is going to be used.
That sounds too complicated. Why not just add a command line option for
jackd for selecting which client to autoconnect to? 
7:40 p.m.
New subject: why shouldn't clients autoconnect to jack
On Mon, Mar 23, 2009 at 11:14:10PM +0100, Kjetil S. Matheussen wrote:
The problem with jack is that application
writers simply don't bother to do all the work required
to handle configurable connection handling,
and instead they just autoconnect to the physical outputs.
So they are the ones responsable for the resulting mess.
If jack had autoconnected by default, we wouldn't
have
had this problem.
We would still have it.
Whatever autoconnect scheme jack could provide, it
would not please some app authors. They would want
to be sure to be connected to playback-1 and -2
while jack might connect them to -7 and -8, and
that would actually make more sense than wanting
to autoconnect in the first place. So they would
just bypass jack's --no-autoconnect option by doing
it themselves.
You can't stop people from behaving in uncivilised
ways or being rude by law, nor by being polite
yourself. In the same way you can't stop apps from
autoconnecting by trying to make it impossible, or
by providing an alternative. The problem is not
technical, it is the attitude of application authors
thinking they can decide in the user's place.
Ciao,
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.
5726
days inactive
5726
days old
linux-audio-user@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Fons Adriaensen -
Kjetil S. Matheussen -
nescivi