[RFC] default port name patch

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

[RFC] default port name patch

Pieter Palmers
I'd like to propose the attached patch that switches the default port
name back to the previously used port names (i.e. the names provided by
the backend). The freebob/firewire backends (usually) provide meaningful
names for the ports, and it's rather inconvenient to have them
overridden by the system* names that don't really say anything. The
system* port names are kept as aliases such that they can keep their
intended functionality, which is (AFAIK) easing auto-connect of (Ardour)
sessions on a system setup that differs from the one they were created on.

Comments very welcome. If no objections are raised in the next, let's
say two, weeks, I'll commit this to SVN.

Greets,

Pieter

Index: jackd/engine.c
===================================================================
--- jackd/engine.c (revision 1062)
+++ jackd/engine.c (working copy)
@@ -964,24 +964,14 @@
 
  if (strncmp (port->name, backend_client_name, len) == 0) {
 
- /* save the backend's own name */
+ /* setup the default 'system:' port aliases */
 
- char name[JACK_CLIENT_NAME_SIZE+JACK_PORT_NAME_SIZE];
- snprintf (name, sizeof (name), "%s", engine->control->ports[i].name);
-
- /* replace input port names, and use backend's original as an alias */
-
  if ((port->flags & (JackPortIsPhysical|JackPortIsInput)) == (JackPortIsPhysical|JackPortIsInput)) {
- snprintf (port->name, sizeof (port->name), "system:playback_%d", out_cnt++);
- strcpy (port->alias1, name);
+ snprintf (port->alias1, sizeof (port->alias1), "system:playback_%d", out_cnt++);
  continue;
  }
-
- /* replace output port names, and use backend's original as an alias */
-
  if ((port->flags & (JackPortIsPhysical|JackPortIsOutput)) == (JackPortIsPhysical|JackPortIsOutput)) {
- snprintf (port->name, sizeof (port->name), "system:capture_%d", in_cnt++);
- strcpy (port->alias1, name);
+ snprintf (port->alias1, sizeof (port->alias1), "system:capture_%d", in_cnt++);
  continue;
  }
  }

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] default port name patch

Stéphane Letz

Le 21 nov. 07 à 10:24, Pieter Palmers a écrit :

> I'd like to propose the attached patch that switches the default  
> port name back to the previously used port names (i.e. the names  
> provided by the backend). The freebob/firewire backends (usually)  
> provide meaningful names for the ports, and it's rather inconvenient  
> to have them overridden by the system* names that don't really say  
> anything. The system* port names are kept as aliases such that they  
> can keep their intended functionality, which is (AFAIK) easing auto-
> connect of (Ardour) sessions on a system setup that differs from the  
> one they were created on.
>
> Comments very welcome. If no objections are raised in the next,  
> let's say two, weeks, I'll commit this to SVN.
>
> Greets,
>
> Pieter
> Index: jackd/engine.c
> ===================================================================
> --- jackd/engine.c (revision 1062)
> +++ jackd/engine.c (working copy)
> @@ -964,24 +964,14 @@
>
> if (strncmp (port->name, backend_client_name, len) == 0) {
>
> - /* save the backend's own name */
> + /* setup the default 'system:' port aliases */
>
> - char name[JACK_CLIENT_NAME_SIZE+JACK_PORT_NAME_SIZE];
> - snprintf (name, sizeof (name), "%s", engine->control-
> >ports[i].name);
> -
> - /* replace input port names, and use backend's original as an  
> alias */
> -
> if ((port->flags & (JackPortIsPhysical|JackPortIsInput)) ==  
> (JackPortIsPhysical|JackPortIsInput)) {
> - snprintf (port->name, sizeof (port->name), "system:playback_
> %d", out_cnt++);
> - strcpy (port->alias1, name);
> + snprintf (port->alias1, sizeof (port->alias1), "system:playback_
> %d", out_cnt++);
> continue;
> }
> -
> - /* replace output port names, and use backend's original as an  
> alias */
> -
> if ((port->flags & (JackPortIsPhysical|JackPortIsOutput)) ==  
> (JackPortIsPhysical|JackPortIsOutput)) {
> - snprintf (port->name, sizeof (port->name), "system:capture_%d",  
> in_cnt++);
> - strcpy (port->alias1, name);
> + snprintf (port->alias1, sizeof (port->alias1), "system:capture_
> %d", in_cnt++);
> continue;
> }
> }

Hum... the situation is not clear at all for me. As far as I remember  
having "system:XXX" port naming was a way to get constant naming  
everywhere so that applications that save connection state using port  
names could restore this state. Then name alias was a way to add a  
more meaningful port names, *assuming* that  connection tools (like  
qjackctl) would display also this alias name.
I guess Paul will have to  explain the initial idea again.

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] default port name patch

Pieter Palmers
Stéphane Letz wrote:

>
> Le 21 nov. 07 à 10:24, Pieter Palmers a écrit :
>
>> I'd like to propose the attached patch that switches the default port
>> name back to the previously used port names (i.e. the names provided
>> by the backend). The freebob/firewire backends (usually) provide
>> meaningful names for the ports, and it's rather inconvenient to have
>> them overridden by the system* names that don't really say anything.
>> The system* port names are kept as aliases such that they can keep
>> their intended functionality, which is (AFAIK) easing auto-connect of
>> (Ardour) sessions on a system setup that differs from the one they
>> were created on.
>>
>> Comments very welcome. If no objections are raised in the next, let's
>> say two, weeks, I'll commit this to SVN.
>>
>> Greets,
>>
>> Pieter

<snip>

>
> Hum... the situation is not clear at all for me. As far as I remember
> having "system:XXX" port naming was a way to get constant naming
> everywhere so that applications that save connection state using port
> names could restore this state. Then name alias was a way to add a more
> meaningful port names, *assuming* that  connection tools (like qjackctl)
> would display also this alias name.
> I guess Paul will have to  explain the initial idea again.

AFAIK you can use both the 'name' and the alias(es) when specifying
ports in a connection call.  This means that application can still store
the connection states in a generic way, but they do have to do implement
support for that specifically (i.e. use the system* aliases instead of
the names). But for the alias system to be useful, the application
should implement support for it anyway (i.e. display the aliases instead
of the system:* name).

While this might not be true for the ALSA backend, for FreeBoB/FFADO
users, it's way more convenient to have the backend names since they
actually mean something, e.g.:

system:capture_1
    freebob_pcm:dev1c_MicIn 1+2 left
system:capture_2
    freebob_pcm:dev1c_MicIn 1+2 right
system:capture_3
    freebob_pcm:dev1c_LineIn 1+2 left
system:capture_4
    freebob_pcm:dev1c_LineIn 1+2 right
system:capture_5
    freebob_pcm:dev1c_SpdifIn 1 left
system:capture_6
    freebob_pcm:dev1c_SpdifIn 1 right
system:playback_1
    freebob_pcm:dev1p_MultiChannel 7.1 Front left
system:playback_2
    freebob_pcm:dev1p_MultiChannel 7.1 Front right
system:playback_3
    freebob_pcm:dev1p_MultiChannel 7.1 Center
system:playback_4
    freebob_pcm:dev1p_MultiChannel 7.1 Subwoofer
system:playback_5
    freebob_pcm:dev1p_MultiChannel 7.1 Rear left
system:playback_6
    freebob_pcm:dev1p_MultiChannel 7.1 Rear right
system:playback_7
    freebob_pcm:dev1p_MultiChannel 7.1 Surround left
system:playback_8
    freebob_pcm:dev1p_MultiChannel 7.1 Surround right
system:playback_9
    freebob_pcm:dev1p_SpdifOut 1 left
system:playback_10
    freebob_pcm:dev1p_SpdifOut 1 right

Greets,

Pieter

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] default port name patch

Fons Adriaensen-2
On Wed, Nov 21, 2007 at 11:43:15AM +0100, Pieter Palmers wrote:

> While this might not be true for the ALSA backend, for FreeBoB/FFADO
> users, it's way more convenient to have the backend names since they
> actually mean something, e.g.:
>
> system:capture_1
>     freebob_pcm:dev1c_MicIn 1+2 left
> system:capture_2
>     freebob_pcm:dev1c_MicIn 1+2 right
> ...

There are a number of separate but interacting issues here.

1. FFADO gives you names that identify the type of signal
   at the HW side, ALSA does not (one wonders why, with all
   it complexity and configurability, ALSA can't do this).

2. Even the names provided by FFADO are meaningless in a
   broader context since in most cases they don't identify
   the _function_ of a particular port in a studio. For
   example they don't tell you that SPDIF out-1,2 are
   the studio monitors, or that certain Line ins/outs
   go to outboard effect processors. The only ports you
   can more or less rely on to have a fixed function in a
   studio are the Mic inputs.

3. The 'System:' port names are useful in a context where
   you have many identical channels that can be patched in
   HW anyway. Using this trick to provide portability of
   sessions just pushes out the problem to the hardware side.
   It's a workable solution in some cases, but a real one
   would take into account port functions, which then of
   course need to be defined somewhere in each setup.

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] default port name patch

Pieter Palmers
Fons Adriaensen wrote:

> On Wed, Nov 21, 2007 at 11:43:15AM +0100, Pieter Palmers wrote:
>
>> While this might not be true for the ALSA backend, for FreeBoB/FFADO
>> users, it's way more convenient to have the backend names since they
>> actually mean something, e.g.:
>>
>> system:capture_1
>>     freebob_pcm:dev1c_MicIn 1+2 left
>> system:capture_2
>>     freebob_pcm:dev1c_MicIn 1+2 right
>> ...
>
> There are a number of separate but interacting issues here.
>
> 1. FFADO gives you names that identify the type of signal
>    at the HW side, ALSA does not (one wonders why, with all
>    it complexity and configurability, ALSA can't do this).
>
> 2. Even the names provided by FFADO are meaningless in a
>    broader context since in most cases they don't identify
>    the _function_ of a particular port in a studio. For
>    example they don't tell you that SPDIF out-1,2 are
>    the studio monitors, or that certain Line ins/outs
>    go to outboard effect processors. The only ports you
>    can more or less rely on to have a fixed function in a
>    studio are the Mic inputs.

This is indeed correct for a studio setup. The example I posted here
however was for a portable breakout box, of which there are quite some
among the firewire devices. These tend to be used in rather volatile
environments, meaning that the "broader context" isn't there.

I personally find it very convenient that I can directly relate the port
name to the physical label on the device. Even though I probably know
the port registration order (hence the system_XX mapping) better than
anyone else.

>
> 3. The 'System:' port names are useful in a context where
>    you have many identical channels that can be patched in
>    HW anyway. Using this trick to provide portability of
>    sessions just pushes out the problem to the hardware side.
>    It's a workable solution in some cases, but a real one
>    would take into account port functions, which then of
>    course need to be defined somewhere in each setup.

I agree that in a multichannel studio setup this is true. But for that I
would propose an optional config file that the user should create for
his/her fixed studio setup. I don't think that this is too much to ask
since it's a one-time effort and when you're setting up a studio like
that I think there are more difficult and/or annoying things. Nor are
studio builders likely to be very novice users. And even if they are,
the config file is optional, and the default would be the
alsa_pcm:playback_XX naming that conceptually does not differ from the
system:playback_xx naming.

In case they use firewire devices naming might be more complex, although
the vendors usually name the channels rather good. The added benefit
being that the channel names are similar to those in other OS'es (and
the device's manual).

Greets,

Pieter



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] default port name patch

Fons Adriaensen-2
On Wed, Nov 21, 2007 at 01:18:04PM +0100, Pieter Palmers wrote:

> Fons Adriaensen wrote:
>
> > There are a number of separate but interacting issues here.
> >
> > 1. FFADO gives you names that identify the type of signal
> >    at the HW side, ALSA does not (one wonders why, with all
> >    it complexity and configurability, ALSA can't do this).
> >
> > 2. Even the names provided by FFADO are meaningless in a
> >    broader context since in most cases they don't identify
> >    the _function_ of a particular port in a studio. For
> >    example they don't tell you that SPDIF out-1,2 are
> >    the studio monitors, or that certain Line ins/outs
> >    go to outboard effect processors. The only ports you
> >    can more or less rely on to have a fixed function in a
> >    studio are the Mic inputs.
>
> This is indeed correct for a studio setup. The example I posted here
> however was for a portable breakout box, of which there are quite some
> among the firewire devices. These tend to be used in rather volatile
> environments, meaning that the "broader context" isn't there.

True. And in such a context, trying to have a 'portable' Ardour
session is probably futile, except for the simplest cases. Sessions
are most likely structured around the available HW, while in a studio
situation the inverse would be true.

> I personally find it very convenient that I can directly relate the port
> name to the physical label on the device. Even though I probably know
> the port registration order (hence the system_XX mapping) better than
> anyone else.

Abolutely agree. ALSA should provide them as well...

> > 3. The 'System:' port names are useful in a context where
> >    you have many identical channels that can be patched in
> >    HW anyway. Using this trick to provide portability of
> >    sessions just pushes out the problem to the hardware side.
> >    It's a workable solution in some cases, but a real one
> >    would take into account port functions, which then of
> >    course need to be defined somewhere in each setup.
>
> I agree that in a multichannel studio setup this is true. But for that I
> would propose an optional config file that the user should create for
> his/her fixed studio setup.

This is exactly what I'd propose. ISTR this topic popped up already
some weeks ago.

> I don't think that this is too much to ask
> since it's a one-time effort and when you're setting up a studio like
> that I think there are more difficult and/or annoying things. Nor are
> studio builders likely to be very novice users.
> ...

Agreed.

> ... the default would be the alsa_pcm:playback_XX naming that
> conceptually does not differ from the system:playback_xx naming.

It does differ, in that it identifies the driver software layer.
Having to choose between the two, I'd prefer 'system:' - the
'alsa_pcm:' part doesn't provide any useful information and is
less 'portable'. Card/interface names would be the first level
of useful info, with port names being the second, and port functions
the third. The name of the software component that creates the device
is in most cases irrelevant to the end user.

Ciao,

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] default port name patch

Paul Davis
In reply to this post by Fons Adriaensen-2
On Wed, 2007-11-21 at 12:21 +0100, Fons Adriaensen wrote:

> On Wed, Nov 21, 2007 at 11:43:15AM +0100, Pieter Palmers wrote:
>
> > While this might not be true for the ALSA backend, for FreeBoB/FFADO
> > users, it's way more convenient to have the backend names since they
> > actually mean something, e.g.:
> >
> > system:capture_1
> >     freebob_pcm:dev1c_MicIn 1+2 left
> > system:capture_2
> >     freebob_pcm:dev1c_MicIn 1+2 right
> > ...
>
> There are a number of separate but interacting issues here.
>
> 1. FFADO gives you names that identify the type of signal
>    at the HW side, ALSA does not (one wonders why, with all
>    it complexity and configurability, ALSA can't do this).

the problem for ALSA is that AFAIK there is no way to reliably determine
the wiring of the pins on chipsets like AC97 and HDA. this is (one of
many) reasons why these devices come with their own drivers on Windows,
where only the motherboard maker/OEM actually knows the actual wiring
topology.

for some cards, it would be possible, but would that be more or less of
a mess?




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] default port name patch

Fons Adriaensen-2
On Wed, Nov 21, 2007 at 09:34:58AM -0500, Paul Davis wrote:

> On Wed, 2007-11-21 at 12:21 +0100, Fons Adriaensen wrote:
>
> > 1. FFADO gives you names that identify the type of signal
> >    at the HW side, ALSA does not (one wonders why, with all
> >    it complexity and configurability, ALSA can't do this).
>
> the problem for ALSA is that AFAIK there is no way to reliably determine
> the wiring of the pins on chipsets like AC97 and HDA. this is (one of
> many) reasons why these devices come with their own drivers on Windows,
> where only the motherboard maker/OEM actually knows the actual wiring
> topology.

That's a known pain... But it doesn't have to be automatic. The names
could be derived from configuration data supplied by the user. You can
configure a lot in ALSA but AFAIK not the port names of a single device.

> for some cards, it would be possible, but would that be more or less of
> a mess?

For those cards which have a mix of very specific ins/outs that
are not even compatible on a functional level it would probably be
useful and not create a mess.

But if one uses Jack for everything (as I suspect most of us here
do), the solution could be at that level, by having an (optional)
command line parameter specifying a file that contains preferred
port names or aliases.

Another idea (which I already coined some time ago) is to factor
out the user level connection API from Jack so it can be given to
some other app (e.g. qjackctl) that can be configured separately
to each user's highly individual desires...

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] default port name patch

Pieter Palmers
In reply to this post by Fons Adriaensen-2
Fons Adriaensen wrote:

> On Wed, Nov 21, 2007 at 01:18:04PM +0100, Pieter Palmers wrote:
>
>> Fons Adriaensen wrote:
>>
>>> There are a number of separate but interacting issues here.
>>>
>>> 1. FFADO gives you names that identify the type of signal
>>>    at the HW side, ALSA does not (one wonders why, with all
>>>    it complexity and configurability, ALSA can't do this).
>>>
>>> 2. Even the names provided by FFADO are meaningless in a
>>>    broader context since in most cases they don't identify
>>>    the _function_ of a particular port in a studio. For
>>>    example they don't tell you that SPDIF out-1,2 are
>>>    the studio monitors, or that certain Line ins/outs
>>>    go to outboard effect processors. The only ports you
>>>    can more or less rely on to have a fixed function in a
>>>    studio are the Mic inputs.
>> This is indeed correct for a studio setup. The example I posted here
>> however was for a portable breakout box, of which there are quite some
>> among the firewire devices. These tend to be used in rather volatile
>> environments, meaning that the "broader context" isn't there.
>
> True. And in such a context, trying to have a 'portable' Ardour
> session is probably futile, except for the simplest cases. Sessions
> are most likely structured around the available HW, while in a studio
> situation the inverse would be true.
>
>> I personally find it very convenient that I can directly relate the port
>> name to the physical label on the device. Even though I probably know
>> the port registration order (hence the system_XX mapping) better than
>> anyone else.
>
> Abolutely agree. ALSA should provide them as well...
>
>>> 3. The 'System:' port names are useful in a context where
>>>    you have many identical channels that can be patched in
>>>    HW anyway. Using this trick to provide portability of
>>>    sessions just pushes out the problem to the hardware side.
>>>    It's a workable solution in some cases, but a real one
>>>    would take into account port functions, which then of
>>>    course need to be defined somewhere in each setup.
>> I agree that in a multichannel studio setup this is true. But for that I
>> would propose an optional config file that the user should create for
>> his/her fixed studio setup.
>
> This is exactly what I'd propose. ISTR this topic popped up already
> some weeks ago.
>
>> I don't think that this is too much to ask
>> since it's a one-time effort and when you're setting up a studio like
>> that I think there are more difficult and/or annoying things. Nor are
>> studio builders likely to be very novice users.
>> ...
>
> Agreed.
>
>> ... the default would be the alsa_pcm:playback_XX naming that
>> conceptually does not differ from the system:playback_xx naming.
>
> It does differ, in that it identifies the driver software layer.
> Having to choose between the two, I'd prefer 'system:' - the
> 'alsa_pcm:' part doesn't provide any useful information and is
> less 'portable'. Card/interface names would be the first level
> of useful info, with port names being the second, and port functions
> the third. The name of the software component that creates the device
> is in most cases irrelevant to the end user.
To say it in your word:
agreed.

:)

Pieter


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel