Hi, Recently I tried to write a client that would nuke the device part of the stream restore database. This works fine but any active streams that match the rule will not have their save_sink|source flag reset when this happens. I think the following patch does this but just wanted to double check this wouldn't trigger some other unwanted behaviour (e.g. in gnome apps) before I push it. I also generate a sink input|source output change subscription message here. This is arguably not "correct" as the sink input itself is not changing, although the rules governing it's routing have. In lieu of a proper subscription system for "routing rules" I just fire this one. Comments? http://colin.guthr.ie/git/pulseaudio/commit/?id=7a7c7e53914f641686fe3fe59d0772e78cdf86ca 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). Comments. 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/]
