[pulseaudio-discuss] Development proposals

[Colin Guthrie]

Hi,

'Twas brillig, and Lennart Poettering at 05/01/09 23:56 did gyre and gimble:
> Hmm, regarding the active "Default" sink:
> 
> Generally I'd like to move away from virtual sinks if
> possible. > Firstly with the arrival of properties on sinks, having
> virtual sinks piggybacked on them will hide all of those
> properties. Then, sinks are something that should be exposed to the
> user, but I fear exposing "virtual" devices won't make you win the
> crown of good user experience.

That's fine, I'm not particularly attached to that idea, I just saw it 
as a means to an end of achieving the desired functionality without too 
much hassle but appreciate your desire here :)

> I wonder if the whole issue could simply be fixed be rearranging the
> UI a bit. Perhaps as a first step renaming "Default sink" to "Fallback
> sink" -- since that's how it actually works now.

This would definitely help yes. Although I do hear people asking time 
and time again for a real "default" sink, so I think this does need to 
be coped with in some capacity.

> 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).

> 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? 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?



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

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.

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?).

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?



> And about the prio list:
> 
> I don't like complex UIs (yes, I designed a couple of them, but I am
> complicated man ;-)). That's why I'd suggest not exposing a prio list
> in the UI (yes, I am a GNOME man!). 

That's fair enough but I don't think it needs to be complex. I'm 
thinking of how the core audio list works on OS X. It's a list and the 
items move up and down it if you set one or other default, so I don't 
think this needs to be "complex" per-se.

> Instead we could probably come up
> with a simple algorithm for building the right order list
> automatically without user invention. And that could work like this:
> 
>   We maintain an ordered list of default sinks to use, one for each
>   entry in the stream rule table, and one for the global default.
> 
>   When a stream is created we go through this default list for its
>   entry in the stream rule table, from top to bottom and take the
>   first sink we find that is actually available. If there is no entry 
>   in the rule table we use the global default list.
> 
>   After a stream has been created or moved we make sure that if there
>   is more than one sink available and any of the sinks the stream is
>   not connected to is in in our list for that stream at a position
>   before the one we are connected to or not in our list at all we
>   place right after the sink we are connected to.
> 
> And that's it. Might be a bit difficult to follow what actually goes
> on. But basically what this algorithm tries to do is to remember how
> you priorize sinks over each other. If you have more than one sink
> around and PA chose the wrong sink for a stream than all you need to
> do is to move the stream to the other sink and PA rearranges its sink
> priority list accordingly and should remember from now on. 
> 
> So instead of exposing yet another UI PA could just learn and you can
> teach it by simply moving streams to the appropriate sinks.
> 
> Does that sound reasonable to you?

I think it does yes and I can understand why you'd not want to expose 
another complex system to the user (and I appreciate to do this the way 
I originally suggested would require protocol changes which is always 
nice to avoid!).

My main concern is just to make things work automatically.

The scenarios I'd like to see "just working" are:

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.

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!).

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?

So overall with this one: dunno :p

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