'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/]
