[pulseaudio-discuss] Priorities for sinks/source

[Lennart Poettering]

On Sun, 30.08.09 17:31, Colin Guthrie (gmane at colin.guthr.ie) wrote:

Heya!

> Do you have any objection to making these priorities user adjustable via  
> the protocol in some way? I know you intend this to be more or less  
> automatic for general out of the box use, but as we've discussed before,  
> the KDE GUI exposes the priority to the user.

Hmpf. Read access to this variable might be an ok thing to do. But
write access? naah

You should not overestimate the meaning of this field. It should be
used only for tie breaking if otherwise more than one sink
(resp. source) are candidates for *a particular purpose*. That means
that most of the time the field is not used and should not be used at
all. 

Now, more specifically, when *should* it be used?

Right now it is used only for selecting the initial default
sink/source. But later on it should be used as well for example when a
sink is removed that was the configured default for a specific role
and we need to find a new sink for a stream of this role. 

As you know I think that the KDE UI for device configuration is not a
particular ... let's say ... convincing design. So trying to bend the
stuff we already have in PA so that it fits what this (misdesigned in
my eyes) KDE UI needs seems the wrong way to do this.

A while back we were talking about extending m-s-r to store a history
of sinks instead of just a single one. It is still on my list to
implement that evntually. The only reasons I didn't do that yet is
that it is a little bit more complex design and nothing i still want
to sneak in right now. (Also I am not entirely sure how the db schema
should look like...)  I believe that if you really think that this KDE
UI design is any good you should map it to this upcoming history logic in PA
than to these priorities.

> I intend to add this priority capability into the module-history that  
> I'm working on (which remembers past sinks and sources and as a side  
> effect allows sinks/sources to be renamed).

Ah, heh. I wrote that parapgraph above before I read this one of
yours... ;-)

Could you elaborate in more detail what this module is supposed to do
and how it relates to m-s-r?

As I understood you by "renaming" you are referring to the device
description, not the sink/source identifying name, right?

> I will update it shortly to also store the priority of the sink and  
> "manage" this such that it can be exposed to the user if so desired.

I am not convinced that this priority value should be used for more
than tie breaking, i.e. last resort decisions.

> I know you don't want this kind of functionality as a general rule for  
> Gnome, but is there any logical problem (e.g. in terms of the  
> implementation or intentions for the future) with me using it this way?

For that to answer I'd need to understand more exactly what you are
trying to do! Please elaborate!

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4