[LAU] why shouldn't clients autoconnect to jack

[nescivi]

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