[pulseaudio-discuss] RFC stream-restore save_sink|source flag reset & more musings on device selection.

[Colin Guthrie]

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