Beyond good & evil of autoconnect

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Beyond good & evil of autoconnect

Sampo Savolainen
Hello everyone,

I hope I haven't missed anything important when skimming through all the
posts about why someone wants autoconnect and why someone else doesn't
want it. I might be repeating what others have said, but my main point
is to show that we can have the best of both (or, at least I can't think
of any reason why we couldn't).

I think we can all agree on a few points:

 a) Some people want autoconnect
 b) Some people don't want it
 c) Autoconnect works for some applications
 d) Some applications just are too complicated for autoconnect

A is a regular joe (like me, I like xmms connecting to 1 & 2)
B is for full control
C is applications like xmms
D is applications like Ardour

The second issue about autoconnect is that where should it connect to.
I'd say this is a global configuration parameter. Why not let jackd tell
the application where to autoconnect and whether the users wants to have
autoconnect.

Imagine a new command line parameter to jack:

jackd --auto-connect-outputs="alsa_pcm:playback_8,alsa_pcm:playback_9"

  or

jackd --no-auto-connect

The auto connect list could be a list of n ports. n >= 1. The default
would be playback_1 & playback_2. These ports could be non-existant at
startup, they could be applications which are loaded later.

In the jack API, we could have a command to .. autoconnect! The
autoconnect would then connect the software's outputs to the
auto-connect ports, or do nothing if autoconnect is off.

We could also have a sane default like:
"alsa_pcm:playback_1,alsa_pcm:playback_2", which would work for most
people. Most people _do_ expect xmms to make sounds when you press play.

----

This way, the outputs used for common regular-Joe applications like xmms
or mplayerplug-in would work even for the types who don't want to use
outputs 1 & 2 (this is for you Ron!).

Is there something which this model wouldn't cover? At least it covers
A, B, C & D

Most stuff beyond the complexity of this model is a job for internal
options, session options, lash data or patchbay. At least in my opinion.

Please, correct or ignore me if I'm wrong. :)

--
Sampo Savolainen <[hidden email]>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Kjetil S. Matheussen

Sampo Savolainen:
> The second issue about autoconnect is that where should it connect to.
> 'd say this is a global configuration parameter. Why not let jackd tell
> the application where to autoconnect and whether the users wants to have
> autoconnect.

Yes, exactly. And that is what I proposed in the beginning of the
thread. :-)



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

melanie-36
And I seconded that. Though I still favour my "pseudo port name" scheme
over an api call, simply because correctly autoconnecting with pseudo
ports is as simple as hardcoding a specific name. It's a solution so
simple, yet elegant, that application developers will not need much
persuasion to adopt it, and the api signature is not touched by it, either.
Also, that may lead to a general port aliasing capability, not a bad
thing, imho.

Melanie

Kjetil S. Matheussen wrote:

> Sampo Savolainen:
>> The second issue about autoconnect is that where should it connect to.
>> 'd say this is a global configuration parameter. Why not let jackd tell
>> the application where to autoconnect and whether the users wants to have
>> autoconnect.
>
> Yes, exactly. And that is what I proposed in the beginning of the
> thread. :-)
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel
>
>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Glynn Clements
In reply to this post by Sampo Savolainen

Sampo Savolainen wrote:

>  c) Autoconnect works for some applications
>  d) Some applications just are too complicated for autoconnect

Whether or not autoconnecting is appropriate depends not upon the
application, but upon the context in which it is run.

A large part of the problem is that the only "fixed" ports are the
physical outputs. The other ports get named according to PID of the
process which created them, so their names vary from session to
session. Consequently, applications which want to autoconnect to
/something/ usually connect directly to the physical outputs.

If you have N JACK applications, connecting to the physical outputs is
usually the wrong thing to do for N-1 of them. Ironically, the
applications which are most likely to autoconnect (media players) are
the ones for which connecting to the physical outputs is least likely
to be correct.

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Sampo Savolainen
In reply to this post by Sampo Savolainen
Quoting Glynn Clements <[hidden email]>:

>
> Sampo Savolainen wrote:
>
> >  c) Autoconnect works for some applications
> >  d) Some applications just are too complicated for autoconnect
>
> Whether or not autoconnecting is appropriate depends not upon the
> application, but upon the context in which it is run.

I disagree. Some applications are made for "listening to music", some
applications are made to be "effects processors".

When you want to listen to music, you don't normally want to fiddle with
connections. If you use an effects processor, you normally want to connect
it explicitly the way to want it to be connected.

Some people have said that they use complicated effects setups for
listening, that's possible with this scheme as well. You could configure the
autoconnect port names to the effects processor you use for your room
correction etc.

The context matters, yes. And that's why this would be configurable. You
could say no to autoconnect in general, or define ports where to use.


Via a patchbays, like qjackctl, and session management, like LASH or ardour
sessions, we already have _all_ the power available to us on the
"professional" (whatever that means) side of things.

What we _need_ is a way to make normal day-to-day application work in
different environments. Because jackd doesn't have a autoconnect policy, we
get these bastard applications like xmms & mplayer, which just connect to
the first physical ports and offer no configuration (at least mplayerplug-in
doesn't). The fact that they autoconnect tells us that these applications
need such behaviour.

> A large part of the problem is that the only "fixed" ports are the
> physical outputs. The other ports get named according to PID of the
> process which created them, so their names vary from session to
> session. Consequently, applications which want to autoconnect to
> /something/ usually connect directly to the physical outputs.

Ardour is always name "ardour", unless you specify a different name at the
command line.

You can give an explicit name for an instance of jack-rack via the -s
-parameter.

You can do this probably to almost any application. From my point of view,
if an application doesn't offer this possibility, it's the application which
is borked rather than jackd.

> If you have N JACK applications, connecting to the physical outputs is
> usually the wrong thing to do for N-1 of them. Ironically, the
> applications which are most likely to autoconnect (media players) are
> the ones for which connecting to the physical outputs is least likely
> to be correct.

Exactly. That's why it would be the applications which are made for the
"regular joes", which are made for _listening_ to music (or any sound),
would use the autoconnect API. The N-1 applications you speak of would never
touch that part of the API.


  Sampo





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Glynn Clements

Sampo Savolainen wrote:

> > If you have N JACK applications, connecting to the physical outputs is
> > usually the wrong thing to do for N-1 of them. Ironically, the
> > applications which are most likely to autoconnect (media players) are
> > the ones for which connecting to the physical outputs is least likely
> > to be correct.
>
> Exactly. That's why it would be the applications which are made for the
> "regular joes", which are made for _listening_ to music (or any sound),
> would use the autoconnect API. The N-1 applications you speak of would never
> touch that part of the API.

You still don't get it. Whether or not the application should
autoconnect, and to what, depends not upon the application but upon
the context in which it is run.

The "N-1 applications" which /shouldn't/ be autoconnecting are the
media players. They don't have enough information to decide what (if
anything) they should be connecting to. An application-based
preference is of no use, because the details can change from session
to session.

With a conventional hi-fi, pressing the "play" button on the CD player
doesn't result in the CD player automatically being selected as the
source. It's signal will be ignored until the user switches the signal
selector from "Phono" to "CD"; at which point, whether the signal goes
to one or the other set of speakers, or to the headphones, is up to
the amplifier, not the CD player.

The reason why most applications auto-connect is because that's the
only option provided by the audio interfaces for which they were
designed (e.g. OSS or ALSA). If the application doesn't connect
itself, nothing else is going to connect it.

JACK is a completely different situation. It's entire purpose is to
route audio between multiple applications and (optionally) physical
inputs and outputs. Giving the application the final say only works
when you only have one application.

From this discussion, it's quite clear that allowing the connection
manager to reliably veto any attempts at autoconnection is going to be
an essential feature. Relying upon applications to behave themselves
simply isn't going to suffice.

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Paul Davis
On Wed, 2006-03-08 at 02:31 +0000, Glynn Clements wrote:
> With a conventional hi-fi, pressing the "play" button on the CD player
> doesn't result in the CD player automatically being selected as the
> source. It's signal will be ignored until the user switches the signal
> selector from "Phono" to "CD"; at which point, whether the signal goes
> to one or the other set of speakers, or to the headphones, is up to
> the amplifier, not the CD player.

when you power up my NAD amplifier, "CD" is the input source selected by
default, which is right for the vast majority of users of the product.

just a point to keep in mind.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Sampo Savolainen
In reply to this post by Sampo Savolainen
Quoting Glynn Clements <[hidden email]>:

> You still don't get it. Whether or not the application should
> autoconnect, and to what, depends not upon the application but upon
> the context in which it is run.

No, I don't.

> The "N-1 applications" which /shouldn't/ be autoconnecting are the
> media players. They don't have enough information to decide what (if
> anything) they should be connecting to. An application-based
> preference is of no use, because the details can change from session
> to session.

Ah, but in my proposition the context _would_ be known. At least enough
information of the context will be known via the user-specified autoconnect
ports, so that the applications can operate in a usable fashion.

> With a conventional hi-fi, pressing the "play" button on the CD player
> doesn't result in the CD player automatically being selected as the
> source. It's signal will be ignored until the user switches the signal
> selector from "Phono" to "CD"; at which point, whether the signal goes
> to one or the other set of speakers, or to the headphones, is up to
> the amplifier, not the CD player.

But wouldn't you rather that pressing "play" would result in you hearing
music?  Why else would the user press the "play" button than to hear music?
A DJ or an audio engineer is a different thing altogether.

I'm guessing the reason why conventional hi-fi's don't work like that is
because the don't have mixer circuits, only relays which select between inputs.

> The reason why most applications auto-connect is because that's the
> only option provided by the audio interfaces for which they were
> designed (e.g. OSS or ALSA). If the application doesn't connect
> itself, nothing else is going to connect it.

The main reason why applications auto-connect is because the point of the
application is to make audible sound (among other things).

Would you like to manually connect mplayer every time you used it? You would
start mplayer, immediately press space to pause the video, then connect
mplayer's outputs via qjackctl's connection dialog, then select mplayer and
press space to start the output.

I hope not! But, in case you or someone else wants to work like this, you
could start jackd with --no-autoconnect and manually connect as you please.

> JACK is a completely different situation. It's entire purpose is to
> route audio between multiple applications and (optionally) physical
> inputs and outputs. Giving the application the final say only works
> when you only have one application.
>
> From this discussion, it's quite clear that allowing the connection
> manager to reliably veto any attempts at autoconnection is going to be
> an essential feature. Relying upon applications to behave themselves
> simply isn't going to suffice.

This is basically the same thing as a connection manager. Jackd works as a
connection manager which knows whether applications should autoconnect or not.

Give me the design for a powerful, yet easy-to use connection manager which
will work without a gui and does things better than the model I'm
suggesting. I believe none such exists and I also believe that this model
will serve 99%. But please, prove me wrong!

From my point of view, this is a clear cut case. There are two sorts of
applications: consumer "cd player" applications like xmms, mplayer, firefox
plugins etc. and professional "audio creation" applications.

ALL consumer applications will want to autoconnect. Altough, maybe not in a
esoteric pro-environement (hence the --no-autoconnect parameter i'm
suggesting). The issue is mainly where to autoconnect (hence the possibility
to give a list of ports to jackd).

NO profesionnal application will want to autoconnect. That's why to use the
API call to autoconnect is a decision taken by the application designer.
Audio creation applications will connect to jackd ports as it's session file
indicates, or LASH tells it to, or just plainly don't connect anywhere.

 My 0.02€
  Sampo


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Alfons Adriaensen-2
On Wed, Mar 08, 2006 at 10:42:45AM +0200, Sampo Savolainen wrote:

> But wouldn't you rather that pressing "play" would result in you hearing
> music?  Why else would the user press the "play" button than to hear music?
> A DJ or an audio engineer is a different thing altogether.

I can easily imagine 'domestic' situations where I wouldn't want this
to happen.

> I'm guessing the reason why conventional hi-fi's don't work like that is
> because the don't have mixer circuits, only relays which select between inputs.

Relays ? Most hifi today would just use some cheap single-chip solution to
switch / mix signals. Mixing is no more complicated than switching. It's
even easier in most cases. This has nothing to do with the question at
hand.

> Would you like to manually connect mplayer every time you used it? You would
> start mplayer, immediately press space to pause the video,

Starting the app shouldn't start playback in the first place. Please gimme
the time to select a track for example.

> then connect
> mplayer's outputs via qjackctl's connection dialog, then select mplayer and
> press space to start the output.
>
> I hope not! But, in case you or someone else wants to work like this, you
> could start jackd with --no-autoconnect and manually connect as you please.

If I would use 'media players' with jack, they'd probably be started and
connected once and just sit there until they are used. I see no more need
to start and stop them for each track I'd want to hear as I see for a
physical player to be switched on and off all the time.

> This is basically the same thing as a connection manager. Jackd works as a
> connection manager which knows whether applications should autoconnect or not.

I still don't see why jackd or any connection manager should be involved in
all this.  All that's required is for every app to do the decent thing and
offer configuration options that determine if it will autoconnect, and it it
does, what to. There could be a environment variable defining the preferred
ports, just as there are such variables for many other user preferences.
In other words, KISS.

--
FA







-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

melanie-36
Hi.

Alfons Adriaensen wrote:
> If I would use 'media players' with jack, they'd probably be started and
> connected once and just sit there until they are used. I see no more need
> to start and stop them for each track I'd want to hear as I see for a
> physical player to be switched on and off all the time.

Well, first, I would not want memory hungry, fancy-gui players hanging
around all the time.

Also, I use mplayer, not gmplayer. It is a command line tool, and I use
it as such. That means I start it with the track I want to see and when
that track is done, it terminates.

Another issue would be with video or audio embedded in webpages. That
also starts immediately.

Connecting ports under application control is a must, but the default
should be set by the user.

Again, I'd like to put forward my port alias idea. Using that simple
means instead of complicated new API calls, which app developers would
likely not adopt, seem to be the simplest way.

If I were to write an app, I would prefer the ability to hardcode a
name, because it produces the simplest, most readable code.

Melanie



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Glynn Clements
In reply to this post by Sampo Savolainen

Sampo Savolainen wrote:

> From my point of view, this is a clear cut case. There are two sorts of
> applications: consumer "cd player" applications like xmms, mplayer, firefox
> plugins etc. and professional "audio creation" applications.

I couldn't disagree more.

> ALL consumer applications will want to autoconnect.

No. The desirability of autoconnection depends upon the context, not
the application.

1. There's no reason why you should need a different media player for
a "professional" environment. A media player's job is to provide an
audio source; what to do with that source is the job of the connection
manager. In the physical world, a turntable will work just as well in
a living room as in a club; you just won't be connecting it to a
mixing desk and kilowatt amplifiers in your living room.

2. The issue isn't limited to "professional" environments. You might
have one setup when you are managing your music collection while
sitting at the computer, and a completely different setup if you're
using it as an audio server while sitting in the living room. You
might even be managing your music collection sitting at the computer
while someone else is sitting in the living room and using it as an
audio server.

Applications running in "simple" environments should be autoconnected
(by something other than the application); applications running in
more complex environments probably shouldn't be (well, they may be
autoconnected /somewhere/, but the application won't be able to
correctly decide where).

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

cannam
In reply to this post by Sampo Savolainen
On Sunday 05 Mar 2006 22:32, Sampo Savolainen wrote:
> Most stuff beyond the complexity of this model is a job for internal
> options, session options, lash data or patchbay. At least in my opinion.

I think the only problem that can't already be resolved using existing tools
and a big bat is the problem of what an application should do the very first
time you run it.  After that, it can always be a question of application
preferences (defaulting presumably to whatever was decided the first time).

There are three agents involved in this decision:

(1) The user, who has some preconceived idea about when or whether they want
    applications to autoconnect

(2) The application, which knows the purpose of each of its output ports

(3) jackd, which knows (to a first approximation) what the available ports
    for autoconnection are.

Of course (3) can be eliminated if you get the same information from the user.  
But you can't eliminate (1) or (2).  Consequently neither the application nor
a patchbay manager can make a satisfactory guess _on its own_ about what the
application should do the first time it's used.

For example: Ardour.  Ardour does autoconnection about as well as it's
possible to do given the current tools.  The default install autoconnects
auditioner and click to playback 1 and 2 by default in the first new session.  
A patch manager couldn't get this right the first time it saw Ardour, because
it wouldn't know to connect only those ports, and it wouldn't know whether
the session in use was configured to connect them or not -- it would do too
little, or far too much.  Ardour doesn't always get it right either, because
its default ports are hardcoded in an .rc file, and it would work rather
better if it could ask jackd which ports the user expects to be listening to
on this occasion and so pick up more sensible defaults.

> jackd --auto-connect-outputs="alsa_pcm:playback_8,alsa_pcm:playback_9"
> jackd --no-auto-connect

I think this would be acceptable, certainly an improvement on the present
situation.  It would be nice if a JACK app could also change these values
without having to restart JACK, so that a user could set them up easily in a
patch manager or whatever, or change them when they add some new processing
block before the final physical outputs.


Chris


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Sampo Savolainen
In reply to this post by Sampo Savolainen
Quoting Glynn Clements <[hidden email]>:

> > ALL consumer applications will want to autoconnect.
>
> No. The desirability of autoconnection depends upon the context, not
> the application.

Yes. Exactly what I mean. Think about this: if the context is such, that
autoconnect is appropriate the applications which are very simple
output-only apps, they would autoconnect. If the context bans autoconnect,
they won't do it.

The designer would make the decision whether to make the application
"autoconnect ready". The user of the application decides whether autoconnect
is used and if so, to which ports. All via jackd parameters.

> 1. There's no reason why you should need a different media player for
> a "professional" environment. A media player's job is to provide an
> audio source; what to do with that source is the job of the connection
> manager. In the physical world, a turntable will work just as well in
> a living room as in a club; you just won't be connecting it to a
> mixing desk and kilowatt amplifiers in your living room.

There is no reason in this model why you couldn't use the same media player.

When you are just browsing the web etc. you are running jackd with
parameters which suit that sort of work: you don't need low latency to add
workload to your system, you can enable autoconnect to make your life
easier: when mplayerplug-in starts, you don't need to connect it to get sound.

When you are recording a soundscape for a video, you can run jackd with low
latency and disable autoconnect so that you can manually connect mplayer to
the bus in ardour that you want to control the sound with.

> 2. The issue isn't limited to "professional" environments. You might
> have one setup when you are managing your music collection while
> sitting at the computer, and a completely different setup if you're
> using it as an audio server while sitting in the living room. You
> might even be managing your music collection sitting at the computer
> while someone else is sitting in the living room and using it as an
> audio server.

Exactly. In my proposal you would control this via the parameters given to
jackd at startup.

The parameters you use jack with (sound card, latency, realtime, port counts
etc.) already define the sort of context you are working with. Whether it's
a realtime low-latency use, or a more laid-back desktop environment. This
would be one parameter more to that context.

> Applications running in "simple" environments should be autoconnected
> (by something other than the application); applications running in
> more complex environments probably shouldn't be (well, they may be
> autoconnected /somewhere/, but the application won't be able to
> correctly decide where).

It's quite apparent that we don't see eye to eye on this subject. Or maybe
we do, but don't understand eachother. :)

Let's let the brilliant people behind jackd decide what to do about it. What
is apparent, from the "heated" discussion is that we both want something to
be done about it.

(btw. Melanie, the port aliases are not a bad idea at all either. It would
fit in the current API nicely)

 Sampo



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Esben Stien
Sampo Savolainen <[hidden email]> writes:

> When you are just browsing the web etc. you are running jackd with
> parameters which suit that sort of work: you don't need low latency

This might not be true for the coming revolution of VRML worlds;).

--
Esben Stien is b0ef@e     s      a            
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
          [sip|iax]:   e     e
           jid:b0ef@    n     n


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

riwright
In reply to this post by cannam

I've collected the relevant parts of ideas suggested by others that I
believe just about forms a solution.  Comments below....



Melanie wrote:

>
> Another issue would be with video or audio embedded in webpages. That
> also starts immediately.
>
> Connecting ports under application control is a must, but the default
> should be set by the user.
>
> Again, I'd like to put forward my port alias idea. Using that simple
> means instead of complicated new API calls, which app developers would
> likely not adopt, seem to be the simplest way.
>
> If I were to write an app, I would prefer the ability to hardcode a
> name, because it produces the simplest, most readable code.
>
> Melanie
>
>

Chris Cannam wrote:

>I think the only problem that can't already be resolved using existing tools
>and a big bat is the problem of what an application should do the very first
>time you run it.  After that, it can always be a question of application
>preferences (defaulting presumably to whatever was decided the first time).
>
>There are three agents involved in this decision:
>
>(1) The user, who has some preconceived idea about when or whether they want
>    applications to autoconnect
>
>(2) The application, which knows the purpose of each of its output ports
>
>(3) jackd, which knows (to a first approximation) what the available ports
>    for autoconnection are.
>
>Of course (3) can be eliminated if you get the same information from the user.  
>But you can't eliminate (1) or (2).  Consequently neither the application nor
>a patchbay manager can make a satisfactory guess _on its own_ about what the
>application should do the first time it's used.
>
>For example: Ardour.  Ardour does autoconnection about as well as it's
>possible to do given the current tools.  The default install autoconnects
>auditioner and click to playback 1 and 2 by default in the first new session.  
>A patch manager couldn't get this right the first time it saw Ardour, because
>it wouldn't know to connect only those ports, and it wouldn't know whether
>the session in use was configured to connect them or not -- it would do too
>little, or far too much.  Ardour doesn't always get it right either, because
>its default ports are hardcoded in an .rc file, and it would work rather
>better if it could ask jackd which ports the user expects to be listening to
>on this occasion and so pick up more sensible defaults.
>
>  
>
>>jackd --auto-connect-outputs="alsa_pcm:playback_8,alsa_pcm:playback_9"
>>jackd --no-auto-connect
>>    
>>
>
>I think this would be acceptable, certainly an improvement on the present
>situation.  It would be nice if a JACK app could also change these values
>without having to restart JACK, so that a user could set them up easily in a
>patch manager or whatever, or change them when they add some new processing
>block before the final physical outputs.
>
>
>Chris
>
>
>  
>

(btw. Melanie, the port aliases are not a bad idea at all either. It would
fit in the current API nicely)

 Sampo




Without trying to take credit for these ideas, I'd like to organize them and see if that rounds out a viable connection policy.


1) JACK should have a --no-auto-connect feature (as Chris suggests, it would be nice if this was changable in runtime) for those users who want to guarantee that any auto-connect feature of any client apps is overridden.  This is important mostly for pros who can damage valuable equipment (or someone's hearing!) if unexpected behavior occurs.

This element absolutely insures against auto-connection for users who don't want it.


2) Client apps should be desiged and coded with *user configurable* auto-connection options.  It'd be nice if the auto-connect options were presented to the user when the app is first run, with the default of the auto-connect options tailored for the inexperienced user who wants the audio to Just Play (i.e. connect to L/R PC speaker outputs -- this could utilize output port aliases as Melanie suggests....more below).  These default options should be somewhat standardized:  "connect stereo", "connect all audio streams" (for known filetypes, i.e. 5.1 surround), "connect-none", etc. -- similar to the options in xmms-jack mentioned earlier.  For example, media players' options could default to the "connect stereo" options so inexperienced users just click "OK/Accept" at the first-run dialog box.

This element addresses Chris' point #1 where the user can apply auto-connection wishes for every application AND Chris' point #2 that applications have some idea about where certain audio channels should be connected.


3) One puzzle piece that appears missing still is an abstraction layer between the available JACK output ports and the physical connectors on the sound card -- understandably since this is driver/product specific.  This is where Melanie's "port aliases" could be functional.  If there were a *user configurable* way to alias standardized names like "Front Left" and "Front Right" to (in my case w/emu10k1 multichannel driver) "alsa_pcm:playback_9" and "alsa_pcm:playback_10", then apps could be written to find and auto-connect to these ports, regardless of the hardware.  I would think these alias mappings could even be supplied by the driver somehow (???).

I think this abstraction layer addreses Chris' point #3, since now JACK will have better than a first approximation for "typical" ports and be able to offer them via standard names (again, configurable by the user).


This solution seems suitable for those who just want audio to automatically play through speakers, yet seems flexible enough (ability to set --no-auto-connect and tell apps not to auto-connect) for those sophisticated users who want to route audio streams through several other JACK clients before routing to output ports.  These complex connection schemes would be handled much like they are right now, through QJC's patchbay or other connection management software.


Thoughts?

Rick



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Glynn Clements

Rick Wright wrote:

> Without trying to take credit for these ideas, I'd like to organize
> them and see if that rounds out a viable connection policy.
>
> 1) JACK should have a --no-auto-connect feature (as Chris suggests, it
> would be nice if this was changable in runtime) for those users who
> want to guarantee that any auto-connect feature of any client apps is
> overridden. This is important mostly for pros who can damage valuable
> equipment (or someone's hearing!) if unexpected behavior occurs.
>
> This element absolutely insures against auto-connection for users who
> don't want it.

My preferred approach would be similar to the way in which X window
managers work.

A single client asserts itself as the authoritative connection
manager, making it the only client which can actually modify the
connection graph. All connection attempts by other clients simply
result in the connection manager being notified of the attempt; it can
either make the requested connection, make some other connection, or
do nothing.

In the absence of a connection manager, clients' connection requests
would be enacted automatically, as happens now.

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Glynn Clements
In reply to this post by Esben Stien

Esben Stien wrote:

> > When you are just browsing the web etc. you are running jackd with
> > parameters which suit that sort of work: you don't need low latency
>
> This might not be true for the coming revolution of VRML worlds;).

Or for watching video, where it's usually quite important that the
audio is synchronised with the video.

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Beyond good & evil of autoconnect

Lee Revell
On Thu, 2006-03-09 at 03:30 +0000, Glynn Clements wrote:

> Esben Stien wrote:
>
> > > When you are just browsing the web etc. you are running jackd with
> > > parameters which suit that sort of work: you don't need low latency
> >
> > This might not be true for the coming revolution of VRML worlds;).
>
> Or for watching video, where it's usually quite important that the
> audio is synchronised with the video.
>

AV playback is not a low latency application.  It does require low
scheduling jitter and good RT scheduling though.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel