Hi, Just for reference I've done a bit more of an in-depth write up of this and my proposal for "fixing" it: http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ Col 'Twas brillig, and Colin Guthrie at 05/02/10 10:11 did gyre and gimble: > FWIW, I am planning a much wider rehash of saved stream devices. To be > honest, the fact that any stream with a role set will inherit the device > override for the whole role is ultimately going to be problematic. > > Recently I suggested that I would not implement stream moving in kmix > while adding PA support for it. While everyone was generally positive > with my general integration work, several people specifically asked me > if I would implement per-app stream moves. Now due to my Phonon > integration pretty much every KDE app has a role set on their streams > (which is nice) but this means that with our current stream routing > system we cannot move an app - only a whole class of app. This is > something that I can do already via the phonon GUI's in KDE4, so really > implementing it in kmix is a bit pointless (for KDE4 apps - would still > be OK for non-phonon apps without a role specified). > > But overall, if the general goal is to get as much metadata into streams > as possible, then eventually all streams will have a role. When this > happens it will become impossible to move *applications* to new devices, > only whole roles. This IMO would be both a regression and a loss of a > rather nice and genuinely useful feature. > > > So I propose the following change (broadly speaking) regarding > stream-restore and device-manager modules. > > 1. Internally we keep a priority list of preferred devices for all our > *roles* and the default case (i.e. a "none" role if you like). (m-d-m > already does this). > 2. We will also keep a priority list of devices for specific > *applications*, although this is optional. > 3. When a new stream comes along it will first try to see if any device > priority list exists for the *application*. If it does not it will fall > back to the device priority list for the role and finally it will fall > back to the device priority list for the default case or "none" role. > 4. It will be possible to move both a role to a new device and (as > currently) and application to a new sink. > 5. If moving a role to a new device then all current streams will be > re-evaluated and moved if appropriate (where "appropriate" means that > the per-application device priority list for that stream is empty). > 6. When moving an application to a new sink we first check to see if a > device priority list exists for that application. If it does not, the > priority list from further up the stage (per-role or default) will be > copied to the applications list. The device they user has specifically > chosen will then be moved to the top of that list. > 7. UIs that support stream moving (e.g. pavucontrol) will be updated to > include an "Automatic" entry in their list of devices to move a stream > to. This Automatic entry basically means, this is handled further up > than me - e.g. per-role based routing and when selecting this option the > per-application device priority list is effectively deleted. > > > Overall I think this approach gives us everything we currently have, but > exposes a bit more clarity to users as to WTF is going on. Having the > stream arbitrarily using a role based rule and having several > applications streams suddenly jump to new devices when you change one > applications device is NOT intuitive to the users. Having this fallback > scheme is much more user friendly and exposing the fact that device > selection is "Automatic" is something that IMO we must do. > > Ultimately I think the principle of picking an appropriate stream > restore rule at stream init and only ever using it is broken and the > above scheme will fix that. > > > (Similarly for volume/mute status restoration, I think a similar > fallback scheme should be employed too - i.e. look for a specific > application rule, otherwise use the role's rule - however if this part > of things keep the current scheme I wouldn't mind too much). -- 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/]
