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

[Colin Guthrie]

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