[pulseaudio-discuss] Priorities for sinks/source

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 01/09/09 00:17 did gyre and gimble:
>> 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... ;-)

:D FWIW, I got my own name wrong! I actually called it 
module-device-manager. That certainly doesn't help things :p

URL is here in my "history" branch (hence why I called the module the 
wrong thing!):
http://colin.guthr.ie/git/pulseaudio/log/?h=history
(freshly rebased but not compile tested, so may be busted...).

I also have patches for pavucontrol to do the renaming (or redescribing 
more accurately) itself.

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

Probably covered here:
http://colin.guthr.ie/2009/06/whats-cooking-in-the-pulse-pot/


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

Yeah, changing the description. I needed a way to query pulse for a list 
of sinks, both currently available and previously active but no longer 
available (the KDE GUI shows both as a priority list with the not 
currently connected devices greyed out). Regardless of whether this is a 
good UI to expose to people or not (personally I actually quite like 
it!), this is how it is presented and I want to find a way to make pulse 
work with it.

Some sort of priority list based routing would be ideal, e.g. something 
that works instead of module-device-restore (or in complement to it). 
Something that re-evaluates and moves streams automatically when a 
higher priority device becomes available.

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

OK. I guess I'll still have to implement my own priority field in 
addition ot this one then. No worries I can do that. It just seemed 
appropriate to use the one already there.

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

I'm sure we've discussed this at length in the past :)

The GUI in KDE is quite simple. For each Role, they give an ordered list 
of sinks. This list includes the currently available sinks and the ones 
you've seen in the past (e.g. Built in, USB, Bluetooth, Network etc.)

http://noneus.de/wp-content/uploads/2008/09/phonon.jpeg

For each item in the list it allows the user to prefer and defer each 
item so that you get the order of preference you want for that role.

Once done, the routing is simple. Traverse the list in order of priority 
and the first device that is currently present is the one we want.

It doesn't do anything clever in terms of automatic prioritisation etc. 
it just leaves the choices up to the user.

While it may be more desirable to leave the routing to pulse internally 
and not expose this to the user as transparently as the KDE GUI does 
(which may be how it works under GNOME), I'm sure there is an 
implementation that will permit this kind of routing policy when used in 
KDE without sacrificing anything or making our lives too difficult!


Of course I've been using Gnome for the last six months or so but will 
probably switch to KDE soon again and try and get this work done.

Col







-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]