[pulseaudio-discuss] Development proposals

[Lennart Poettering]

On Tue, 06.01.09 22:30, Colin Guthrie (gmane at colin.guthr.ie) wrote:

It might be a good thing to document some of these thoughts on this
Wiki page:

http://fedoraproject.org/wiki/Features/VolumeControl

(it's in the Fedora wiki, but that doesn't mean anything except that
the development is done by RH folks...)

> > Alternatively we
> > could simply implicitly drop the saved rules table when the user makes
> > another sink the default. And finally an option could actually be to
> > drop the "automatic remembering" part entirely for the devices and
> > replace it by per-role configuraiton dialogs. i.e. like the old one
> > from GNOME where you can set different devices for Movie, Audio,
> > Events, and Games or so.
> 
> Well this is also how Qt's Phonon does it (categories) so anything that 
> keeps things generally similar between both main desktops could be 
> argued to be "A Good Thing"(tm).

Oh, we actually do it the same way in a way. We don't call it
"categories" but "roles". And unfortunately almost no stream is
properly tagged by the role, except for the system sounds.

Also m-s-r saves/restores voluems/devices per role (and not per app!)
if a role is set.

The question is not whether to do the whole stuff per-role or
not. It's about how the configuration should happen. With the current
m-s-r approach it is: move a stream to the right device and PA will
remember it for all streams of this type from now on. The moving is
thus made persistant. The alternative would be to not have this
automatic learning but instead have it in an explicit UI only. 

Note sure if automatic learning is good or not. For volumes I am sure
it is. It appears logic to me if it is for devices too, but I am not
so sure...

> > So, I am not sure about this one. What do you say?
> 
> Well despite what I said above, I'm not really sold on the categories 
> thing, although it's hard to argue against it being a simple and elegant 
> solution. The problem is how would it work? How would pulse know what 
> "type" a stream is? 

Simply set the media.role property of the stream you are creating to
"video", "music", "game" and so on. This of course is impossible to do
in wrapper APIs that don't support roles/classes/categories (or
whatever you like to call them). GStreamer does support this, the fix
for gst-pulse has been on my todo list for a while and is actually
trivial to do.

> With phonon this is built in as the API is new and 
> thus it forces users to select a category (or at least pushes it 
> heavily) but as pulse has to work with alsa and oss etc. most 
> applications would probably fall into the "Unknown" category I'd
> presume?

Dunno. At least on GNOME most apps use GStreamer. And that can be
fixed easily as mentioned.

I Phonon has this information, is there any chance that this info can
be passed through xine that pa can make use of it?

For the rest there is the option to transparently extend the property
set based on other props via some kind of script (you remember the
thoughts i had about Lua a while back? this was precisely for reasons
like this). i.e. have a couple of scripts that would match the process
name against "mplayer" and then assume a role of "video". But as of
now there is no scripting extension for PA, of course. A short time
fix could be to simply code this in C instead of some scripting
language. And only do it for the most important programs. Should be doable.

> So assuming the categories thing is not going to work, how about just 
> tracking "default" device a bit better in the device restore table?

The roles thing will work.

Also note that all libcanberra events are properly tagged as "event"
role. 

> Could streams that are routed to the "default" sink (e.g. initially) 
> have a property attached to them to say "prefer-default". The device 
> restore module would see this property and would store the "device" as 
> "default" rather than the real sink.
> 
> When the default sink is changed, some module (device-restore?) would 
> notice this and cycle through all running streams and find any that had 
> "prefer-default" property and move them over the new default if they
> do.

Could be done. But is rather intransparent, don't you think? Hmm, but
maybe more transparent than most other solutions.

> This still allows you to move the stream to a specific sink if you want 
> but also allows the "default" behaviour that most people expect.

> So the "move stream" popup menu would be something like:
> +-----------+
> | o Default |
> +-----------+
> |   Sink A  |
> |   Sink B  |
> |   ...     |
> +-----------+
> 
> Picking a real sink would call the API in the same way as just now, but 
> picking "Default" would simply set the property on the stream. A module 
> (device restore again?) would listen for property changes on streams and 
> if this "prefer-default" property was added it would do the moving and 
> update it's table according. (NB I'm not sure if a module can listen for 
> stream property changes - is this possible?).

It's possible via subscriptions. We could add hooks as well.

> This whole approach has a minimal impact (no protocol changes), most of 
> the server side dev is kept inside device-restore and the UI changes are 
> quite minimal too.
> 
> Sensible?

Hmm, the problems is that only "owners" of objects may modify
properties. i.e. the client that created a stream can modify its
properties -- but noone else. But that rule is not for eternity, we
can change that, but probably not as a general API.

So, a possible solution would be like this:

1) make m-s-r not restore the device for streams tagged
   "prefer-default". (trivial)

2) write a tiny module that:
   
          a) each time the default sink changes makes sure that all
             streams tagged "prefer-default" are moved to it.
          b) extends the protocol to allow free changing of the
             "prefer-default"  prop on all streams

And then of course we still need the ordering foo as described below.
> 1. I have a laptop with networking and bluetooth.
> 2. When I go to work, we have a network pulse sink. I'd like it to just 
> use this if it's detected.
> 3. At home I have a BT hifi system. If it's on I'd like to just use it 
> automatically.

(a side note: "bt hifi" is an oxymoron...)

> When these devices are detected, I'd like pulse to just start using them 
> automatically (it would display a little popup notification naturally!). 
> It's really this automatic switching when detected bit that I'd like to 
> get and the way I visualised it was with a priority list and an "active" 
> default sink (e.g. if you've picked a specific sink for a given stream, 
> it wouldn't move when this higher priority sink is discovered, it would 
> only "move" those sinks assigned to the "default" - e.g. it's the 
> "default" that changes not really the individual sinks own preference; 
> dunno if I explained that well!).

I wonder if some people would actually prefer a behaviour like this:
"never move a playing stream: simply let the user do the
switching". Might be a valid way to deal with things.

> Correct me if I'm wrong, but your above suggestion is mostly about 
> finding the right sink for a stream when it starts, and doesn't really 
> address the automatic moving when a preferred sink becomes available?

Yes. But that's where the above mentioned module 2) might come into play.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4