[jackit-devel] Ports names and aliases.

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

[jackit-devel] Ports names and aliases.

Francois.ernoult
Hi all,

Since rev1032 (04-27-2007), Paul added support for ports aliases.

In jackd/engine.c, there's something that change ports names to
"system:(playback|capture)_N" if the port is physical and if its original
name starts with the backend client name.
Correct me if it's not exact.

It causes a problem on interfaces with a lot of I/O. For example, the MOTU
828mkII has 22 inputs and 22 outputs. It's more difficult to find the phone
out labeled system:playback_11 and 12 than dev0_pbk_Phone-L and R.

One other important thing with MOTU interfaces is that the number of I/O
varies depending on the clock frequency and the interface configuration. For
example, on the 828mkII, @96kHz the ADAT out use 4 ports against 8 @48kHz.
ADAT can be completely disabled.
In this case, numbers in ports label makes no sense.

Was this comportment expected?
For my MOTU 828mkII, I prefer commenting out ports labels replacement.

Regards,
Francois


-------------------------------------------------------------------------
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
|

Ports names and aliases

Francois.ernoult
Hi all,

A few weeks ago I asked for a precision about the alias feature:

Why physical ports with original name starting with the backend client name
are renamed to "system:(playback|capture)_N"?

It causes a problem on interfaces with a lot of I/O. For example, the MotU
828mkII has 22 inputs and 22 outputs. It's more difficult to find the phone
out labeled system:playback_11 and 12 than dev0_pbk_Phone-L and R.

One other important thing with MOTU interfaces is that the number of I/O
varies depending on the clock frequency and the interface configuration. For
example, on the 828mkII, @96kHz the ADAT out use 4 ports against 8 @48kHz.
ADAT can be completely disabled.
In this case, numbers in ports label doesn't make sense.


Regards,
Francois


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Stéphane Letz

Le 20 oct. 07 à 11:59, Francois.ernoult a écrit :

> Hi all,
>
> A few weeks ago I asked for a precision about the alias feature:
>
> Why physical ports with original name starting with the backend  
> client name
> are renamed to "system:(playback|capture)_N"?
>
> It causes a problem on interfaces with a lot of I/O. For example,  
> the MotU
> 828mkII has 22 inputs and 22 outputs. It's more difficult to find  
> the phone
> out labeled system:playback_11 and 12 than dev0_pbk_Phone-L and R.
>
> One other important thing with MOTU interfaces is that the number  
> of I/O
> varies depending on the clock frequency and the interface  
> configuration. For
> example, on the 828mkII, @96kHz the ADAT out use 4 ports against 8  
> @48kHz.
> ADAT can be completely disabled.
> In this case, numbers in ports label doesn't make sense.
>
>
> Regards,
> Francois
>


The logic behind port name alias is that a consistent port naming  
system is used everywhere. The idea is that applications that use  
port names in their saved state can restore port connections, even  
when application state is transfered different systems. The "real"  
port name is saved as a "port name allias", that a connection  
management tool like qjackctl could choose to display instead of the  
"system" based naming.

Stephane

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Francois.ernoult
Hi Stéphane,

Thanks for your answer.

> > Why physical ports with original name starting with the backend
> > client name
> > are renamed to "system:(playback|capture)_N"?
> >
>
> The logic behind port name alias is that a consistent port naming
> system is used everywhere. The idea is that applications that use
> port names in their saved state can restore port connections, even
> when application state is transfered different systems. The "real"
> port name is saved as a "port name allias", that a connection
> management tool like qjackctl could choose to display instead of the
> "system" based naming.
>

Ok, it's a good idea. But AFAIK, for now neither qJackCtl nor Ardour can
display (and use) aliases instead of real name.
With interfaces like the MotU 828mkII it's a big problem. For example Phones
outputs are number 11 and 12 in a list of 22 ports. If you have 2
interfaces, the second one ports numbers offset depends on ADAT being
enabled or not on the first one. It's unusable in real situation.

I think it could be more usable with a few improvements:

1. Applications should handle aliases.

2. It should be something to indicate a port is a normal track port (analog,
ADAT, tdiff, etc...) or a monitoring port (phones, dedicated Main analog
out, etc...) or AUX (SPDIF, AES/EBU) and applications saving ports names
should take care of it. Without that, we have to change the routing by hand
if the hardware config changes (I don’t want 2 track being routed to Phones
or regular tracks being routed to the Main-out).
I don't think it's possible to add a "port role" property to ports without
breaking the compatibility with previous jackd versions. We probably may add
something in a port structure. This is not going to be easy!

3. Applications (clients) and backend should handle this "port role".

In the current state, this feature should be at last a compilation option.


Regards,
Francois


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Stéphane Letz

Le 20 oct. 07 à 14:01, Francois.ernoult a écrit :

> Hi Stéphane,
>
> Thanks for your answer.
>
>>> Why physical ports with original name starting with the backend
>>> client name
>>> are renamed to "system:(playback|capture)_N"?
>>>
>>
>> The logic behind port name alias is that a consistent port naming
>> system is used everywhere. The idea is that applications that use
>> port names in their saved state can restore port connections, even
>> when application state is transfered different systems. The "real"
>> port name is saved as a "port name allias", that a connection
>> management tool like qjackctl could choose to display instead of the
>> "system" based naming.
>>
>
> Ok, it's a good idea. But AFAIK, for now neither qJackCtl nor  
> Ardour can
> display (and use) aliases instead of real name.
> With interfaces like the MotU 828mkII it's a big problem. For  
> example Phones
> outputs are number 11 and 12 in a list of 22 ports. If you have 2
> interfaces, the second one ports numbers offset depends on ADAT being
> enabled or not on the first one. It's unusable in real situation.
>
> I think it could be more usable with a few improvements:
>
> 1. Applications should handle aliases.
>
> 2. It should be something to indicate a port is a normal track port  
> (analog,
> ADAT, tdiff, etc...) or a monitoring port (phones, dedicated Main  
> analog
> out, etc...) or AUX (SPDIF, AES/EBU) and applications saving ports  
> names
> should take care of it. Without that, we have to change the routing  
> by hand
> if the hardware config changes (I don’t want 2 track being routed  
> to Phones
> or regular tracks being routed to the Main-out).
> I don't think it's possible to add a "port role" property to ports  
> without
> breaking the compatibility with previous jackd versions. We  
> probably may add
> something in a port structure. This is not going to be easy!
>
> 3. Applications (clients) and backend should handle this "port role".
>
> In the current state, this feature should be at last a compilation  
> option.
>

This kind of discussion has already been done on jack dev list.  
AFAIK, port aliases was a progress on a previously more messy  
situation. Even if the port role seems like an interesting idea, how  
can you be sure to correctly list all the needed "role"? and what  
happens if new roles are added layer on? Not sure it can be handled  
in a satisfactory manner.

Stephane

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Francois.ernoult
> >>> Why physical ports with original name starting with the backend
> >>> client name
> >>> are renamed to "system:(playback|capture)_N"?
> >>>
> >>
> >> The logic behind port name alias is that a consistent port naming
> >> system is used everywhere. The idea is that applications that use
> >> port names in their saved state can restore port connections, even
> >> when application state is transfered different systems. The "real"
> >> port name is saved as a "port name allias", that a connection
> >> management tool like qjackctl could choose to display instead of the
> >> "system" based naming.
> >>
> >
> > Ok, it's a good idea. But AFAIK, for now neither qJackCtl nor
> > Ardour can
> > display (and use) aliases instead of real name.
> > With interfaces like the MotU 828mkII it's a big problem. For
> > example Phones
> > outputs are number 11 and 12 in a list of 22 ports. If you have 2
> > interfaces, the second one ports numbers offset depends on ADAT being
> > enabled or not on the first one. It's unusable in real situation.
> >
> > I think it could be more usable with a few improvements:
> >
> > 1. Applications should handle aliases.
> >
> > 2. It should be something to indicate a port is a normal track port
> > (analog,
> > ADAT, tdiff, etc...) or a monitoring port (phones, dedicated Main
> > analog
> > out, etc...) or AUX (SPDIF, AES/EBU) and applications saving ports
> > names
> > should take care of it. Without that, we have to change the routing
> > by hand
> > if the hardware config changes (I don’t want 2 track being routed
> > to Phones
> > or regular tracks being routed to the Main-out).
> > I don't think it's possible to add a "port role" property to ports
> > without
> > breaking the compatibility with previous jackd versions. We
> > probably may add
> > something in a port structure. This is not going to be easy!
> >
> > 3. Applications (clients) and backend should handle this "port role".
> >
> > In the current state, this feature should be at last a compilation
> > option.
> >
>
> This kind of discussion has already been done on jack dev list.

The change was made 27th or April 2007. I looked for some discussion about
that around this date but I didn't find anything. I will have a closer look.

> AFAIK, port aliases was a progress on a previously more messy
> situation.

It depends on what interface you have. Imagine you have an ardour project
with a MotU Traveler. If you want to switch to a MotU 828mkII you have to
re-route everything anyway. And you don’t see what you are doing because of
those names that don't mean anything.

> Even if the port role seems like an interesting idea, how
> can you be sure to correctly list all the needed "role"? and what
> happens if new roles are added layer on? Not sure it can be handled
> in a satisfactory manner.

I think "track" and "monitor" roles correspond to 95% of the case, and 100%
of what you need to open a project and ear sound. In the current case you
can't. Moreover it could be easy to let the user change the default "role".

What do you mean exactly by "new roles are added layer on"? What doe's do
the current system in a similar case.
I think other ports "role" than "track" and "monitor" can be put in "other"
and ignored by cross interface routing save. Those ports have 99% of chance
to be very interface specific anyway.


Regards,
Francois


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

John Rigg-3
On Sat, Oct 20, 2007 at 02:54:27PM +0200, Francois.ernoult wrote:
> I think "track" and "monitor" roles correspond to 95% of the case,

Not necessarily. Those of us who mix down on an analog mixing
desk (not unusual in a studio situation) would also expect multitrack
outputs.

> and 100%
> of what you need to open a project and ear sound. In the current case you
> can't. Moreover it could be easy to let the user change the default "role".
>
> What do you mean exactly by "new roles are added layer on"? What doe's do
> the current system in a similar case.
> I think other ports "role" than "track" and "monitor" can be put in "other"
> and ignored by cross interface routing save. Those ports have 99% of chance
> to be very interface specific anyway.

Personally I'd rather avoid having jackd decide in the background
what roles my ports have. I don't have a problem with setting
connections manually based on port numbers. I appreciate
that not everyone likes this, but how would you decide what roles
the ports default to without making it inconvenient for somebody?

John

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Francois.ernoult
Hi John,

> > I think "track" and "monitor" roles correspond to 95% of the case,
>
> Not necessarily. Those of us who mix down on an analog mixing
> desk (not unusual in a studio situation) would also expect multitrack
> outputs.

That's what I do when I can.
"Track" could be for output as well as for input.

>
> > and 100%
> > of what you need to open a project and ear sound. In the current case
> you
> > can't. Moreover it could be easy to let the user change the default
> "role".
> >
> > What do you mean exactly by "new roles are added layer on"? What doe's
> do
> > the current system in a similar case.
> > I think other ports "role" than "track" and "monitor" can be put in
> "other"
> > and ignored by cross interface routing save. Those ports have 99% of
> chance
> > to be very interface specific anyway.
>
> Personally I'd rather avoid having jackd decide in the background
> what roles my ports have. I don't have a problem with setting
> connections manually based on port numbers. I appreciate
> that not everyone likes this, but how would you decide what roles
> the ports default to without making it inconvenient for somebody?

I'm completely agreed with you but it doesn't seem that's the chosen
direction. If Jack has a mechanism to automatically reconnect ports no
matter which interface is used, it has to take care of the nature of each
port. I don't need my phones automatically connected to random tracks of my
project.

Regards,
Francois


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Paul Davis
In reply to this post by Francois.ernoult

> Ok, it's a good idea. But AFAIK, for now neither qJackCtl nor Ardour can
> display (and use) aliases instead of real name.
> With interfaces like the MotU 828mkII it's a big problem. For example Phones
> outputs are number 11 and 12 in a list of 22 ports. If you have 2
> interfaces, the second one ports numbers offset depends on ADAT being
> enabled or not on the first one. It's unusable in real situation.

its a *lot* more usable than moving a session or some other "state"
information from one machine to another and finding that it can't be
used *at all* because the port names are completely and utterly
different. its true that the default mapping from my RME h/w to your
MOTU might not be what you want, but at least you will be able to hear
some of the resulting sound.

> I think it could be more usable with a few improvements:
>
> 1. Applications should handle aliases.

we can't make applications do anything. the API is there (err, well,
once we get off our behinds and get a release out).

> 2. It should be something to indicate a port is a normal track port (analog,
> ADAT, tdiff, etc...) or a monitoring port (phones, dedicated Main analog
> out, etc...) or AUX (SPDIF, AES/EBU) and applications saving ports names
> should take care of it. Without that, we have to change the routing by hand
> if the hardware config changes (I don’t want 2 track being routed to Phones
> or regular tracks being routed to the Main-out).
> I don't think it's possible to add a "port role" property to ports without
> breaking the compatibility with previous jackd versions. We probably may add
> something in a port structure. This is not going to be easy!

there is room for 1 more alias for every h/w port. if you want to work
in this way, run a script after jackd starts up that calls jack_alias
for each port to provide suitable aliases.

> 3. Applications (clients) and backend should handle this "port role".

why? what does this have to do with jack (other than providing a way to
name the "roles")? most applications couldn't care less about this.

> In the current state, this feature should be at last a compilation option.

no. the feature is there to ensure a single set of consistently named
ports no matter what platform of backend you are using. making it an
option completely defeats the purpose of that.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Francois.ernoult
Hello Paul,

>
> > Ok, it's a good idea. But AFAIK, for now neither qJackCtl nor Ardour can
> > display (and use) aliases instead of real name.
> > With interfaces like the MotU 828mkII it's a big problem. For example
> Phones
> > outputs are number 11 and 12 in a list of 22 ports. If you have 2
> > interfaces, the second one ports numbers offset depends on ADAT being
> > enabled or not on the first one. It's unusable in real situation.
>
> its a *lot* more usable than moving a session or some other "state"
> information from one machine to another and finding that it can't be
> used *at all* because the port names are completely and utterly
> different. its true that the default mapping from my RME h/w to your
> MOTU might not be what you want, but at least you will be able to hear
> some of the resulting sound.
>

Ok, I understand it can be very useful. Moreover we can try (when it's
possible) to keep the same port order for port that have approximately the
same function. At last I can arrange the MotU's ports order so that it
"looks like" an RME interface as most as possible.

So, the only inconvenient I find is that name displayed by applications
(ardour, qjackctl, etc) doesn't tell anything about which physical port it
corresponds. For MotU interfaces, the original name describes the port.
I don't find this negligible.

Here is my ports list before the aliases implementation:

Backend input:
  dev0_pbk_Main-L
  dev0_pbk_Main-R
  dev0_pbk_Analog1
  [...]
  dev0_pbk_Analog8
  dev0_pbk_Phones-L
  dev0_pbk_Phones-R
  dev0_pbk_SPDIF1
  dev0_pbk_SPDIF2
  dev0_pbk_ADAT1
  [...]
  dev0_pbk_ADAT8

And the same style for the outputs.

The best should be that clients (ardour, qjackctl, ...) display the highest
order alias when available. But I understand it's not the right place to
discuss about that.


Regards,
Francois


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Paul Davis
On Mon, 2007-10-22 at 16:21 +0200, Francois.ernoult wrote:

> Ok, I understand it can be very useful. Moreover we can try (when it's
> possible) to keep the same port order for port that have approximately the
> same function. At last I can arrange the MotU's ports order so that it
> "looks like" an RME interface as most as possible.

this is futile goal, really. what happens when you then try the session
out on a laptop with just a stereo builtin audio interface? with 5.1 ?
etc.

> So, the only inconvenient I find is that name displayed by applications
> (ardour, qjackctl, etc) doesn't tell anything about which physical port it
> corresponds. For MotU interfaces, the original name describes the port.
> I don't find this negligible.

this is true ONLY on OS X and only with certain devices. if you use an
RME or Echo device on OS X, you won't get this "name describes port"
function, because those devices have no concept of "port function".

your whole point is based on what MOTU's driver implementation for OS X
does regarding presenting i/o connector names. this is not a property
shared among all device drivers, not even on OS X, and possibly not even
most device drivers. IIRC, the RME driver doesn't even "name" the
headphone outputs in any special way (i could be wrong).

> The best should be that clients (ardour, qjackctl, ...) display the highest
> order alias when available. But I understand it's not the right place to
> discuss about that.

there is no way to define the "correct" order. if you mean "qjackctl
should provide an option to sort ports by official name, alias 1 or
alias 2, then ok. but thats a much "weaker" request than asking that
JACK pays attention to the device driver implementation.

--p




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Stéphane Letz

Le 22 oct. 07 à 17:44, Paul Davis a écrit :

> On Mon, 2007-10-22 at 16:21 +0200, Francois.ernoult wrote:
>
>> Ok, I understand it can be very useful. Moreover we can try (when  
>> it's
>> possible) to keep the same port order for port that have  
>> approximately the
>> same function. At last I can arrange the MotU's ports order so  
>> that it
>> "looks like" an RME interface as most as possible.
>
> this is futile goal, really. what happens when you then try the  
> session
> out on a laptop with just a stereo builtin audio interface? with 5.1 ?
> etc.
>
>> So, the only inconvenient I find is that name displayed by  
>> applications
>> (ardour, qjackctl, etc) doesn't tell anything about which physical  
>> port it
>> corresponds. For MotU interfaces, the original name describes the  
>> port.
>> I don't find this negligible.
>
> this is true ONLY on OS X and only with certain devices. if you use an
> RME or Echo device on OS X, you won't get this "name describes port"
> function, because those devices have no concept of "port function".

Correct .
CoreAudio API allows driver developers to implement a  
"kAudioDevicePropertyChannelName" property to set a name for the  
channel, but it not often used, even by Apple for its internal  
drivers...

Stephane




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Pieter Palmers
In reply to this post by Paul Davis
Paul Davis wrote:

> On Mon, 2007-10-22 at 16:21 +0200, Francois.ernoult wrote:
>
>> Ok, I understand it can be very useful. Moreover we can try (when it's
>> possible) to keep the same port order for port that have approximately the
>> same function. At last I can arrange the MotU's ports order so that it
>> "looks like" an RME interface as most as possible.
>
> this is futile goal, really. what happens when you then try the session
> out on a laptop with just a stereo builtin audio interface? with 5.1 ?
> etc.
>
>> So, the only inconvenient I find is that name displayed by applications
>> (ardour, qjackctl, etc) doesn't tell anything about which physical port it
>> corresponds. For MotU interfaces, the original name describes the port.
>> I don't find this negligible.
>
> this is true ONLY on OS X and only with certain devices. if you use an
> RME or Echo device on OS X, you won't get this "name describes port"
> function, because those devices have no concept of "port function".
Note that the standard behavior for the FreeBoB / FFADO backend is to
register its ports using the names it finds from device discovery. These
usually are sensible names. This is also true for the MotU firewire
devices. I think Francois refers to this behavior.

On the other hand I do agree with Paul that it is almost impossible to
generalize a port naming scenario.

If I'm not wrong you can use any of the aliases to connect to a port,
regardless of what name is used as 'default alias'. This means that we
could supply a command-line switch that allows a user to use the backend
names instead of the system:* aliases by default.

Another remark that can be made is that the current system:x naming is
not that much different from a 'connect-to-port-x' API, rendering the
actual use of names somewhat pointless.

I think having a user editable config file that is used by jackd to
initialize the shown aliases is the best way to go. That way it's a
one-time effort to set up the config file for your setup, and after that
the port names make sense. The system:x names can be used as aliases
such that the try-to-connect-as-good-as-possible functionality is retained.

Greets,

Pieter

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Fons Adriaensen-2
On Mon, Oct 22, 2007 at 06:30:38PM +0200, Pieter Palmers wrote:

> I think having a user editable config file that is used by jackd to
> initialize the shown aliases is the best way to go. That way it's a
> one-time effort to set up the config file for your setup, and after that
> the port names make sense. The system:x names can be used as aliases
> such that the try-to-connect-as-good-as-possible functionality is retained.

Agreed 100%. And the name of this optional file should be
a command line parameter to jackd. Then it is the user's
responsability to supply the correct file name when using
parameter sets that modify the number or type of channels.
And it's still easy to have consistent parameter sets for
desktop icons or menus without having to rewrite the file.

Ciao,

--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ports names and aliases

Fernando Lopez-Lezcano
On Mon, 2007-10-22 at 22:43 +0200, Fons Adriaensen wrote:

> On Mon, Oct 22, 2007 at 06:30:38PM +0200, Pieter Palmers wrote:
>
> > I think having a user editable config file that is used by jackd to
> > initialize the shown aliases is the best way to go. That way it's a
> > one-time effort to set up the config file for your setup, and after that
> > the port names make sense. The system:x names can be used as aliases
> > such that the try-to-connect-as-good-as-possible functionality is retained.
>
> Agreed 100%. And the name of this optional file should be
> a command line parameter to jackd. Then it is the user's
> responsability to supply the correct file name when using
> parameter sets that modify the number or type of channels.
> And it's still easy to have consistent parameter sets for
> desktop icons or menus without having to rewrite the file.

And the command line specified file would override the default user
configuration file in ~/.jackdaliases, and that would override (or not)
the system configuration file in /etc/jackdaliases :-)

Makes for an easy setup when shared home directories are used between
machines that can have different audio configurations.

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel