Re: [LAU] why shouldn't clients autoconnect to jack

Hiho,

On Monday 23 March 2009 18:14:10 Kjetil S. Matheussen wrote:
> > On Monday 23 March 2009 14:58:38 Kjetil S. Matheussen wrote:
> > > Without that, the other things I said would have been incredibly
> > > stupid.
> > >
> > > > 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?
> >
> > 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.
>
> 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.

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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Tue Mar 24 04:15:01 2009