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

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 05/02/10 14:29 did gyre and gimble:
> pe, 2010-02-05 kello 10:11 +0000, Colin Guthrie kirjoitti:
>> 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.
> 
> You seem to fire the event unconditionally after
...
> Is it guaranteed that the previous value is always TRUE? If not, I think
> you should write

Ahh excellent point. Thanks.

>> 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.
> 
> Can you give an example of a case where individual app control (as
> opposed to role control) is needed? Above you argue that it's
> non-obvious to the user that by moving Rhythmbox, Amarok moves too. I
> agree. But I think the problem is that the UI emphasizes the application
> instead of the role. Maybe it would be best to display all roles all the
> time, like the Event role is now displayed always. The UI could, in
> addition, show the individual streams under the roles, if any are
> currently active.

Well under KDE, the Phonon UI preferences allow you to basically pick
the device to use for a given category (this is probably akin to what
you suggest by showing all the categories all the time). I surmised that
this was sufficient level of control over device preference (basically
due to that is what was exposed by the KDE guys so I figured that was
the level of control "they" wanted).

On my blog when I mentioned this I had several people ask for per-app
stream moving to be implemented:
http://colin.guthr.ie/2010/01/mix-it-up/#comments

So these are the "use cases".

Personally I think a different UI that showed the apps under their
appropriate role heading is a valid UI if it's agreed that per-stream
device choice is no longer going to be supported, but I don't really
think that's something we can realistically entertain (aside from API
changes (or irregularities), I think it's a genuinely useful feature).

So I don't really have a problem with the current ability to work at a
per-app granularity, nor do I have a problem with a per-app device
priority list that is updated automatically internally so that stream
moves are recorded and that the last specifically chosen device which is
available is the one that will be used, nor do I have a problem with
this same system being implemented for roles. Where I have a problem is
the lack of transparency with regards to which rule is active for a
given sink.

I guess your UI suggestion would imply that a role-based routing rule
was in place for all cases except when a given stream has no role.

So I guess a UI like (where [ ] encloses a device choice popup thingy):


- Event Sounds                  [ Internal Audio ]
- Music                         [ USB Speakers ]
  - Amarok: Girls Aloud - Squealing like Chickens
  - RhythmBox: Metallica - Fade to Black
- Video                         [ HDMI Audio ]
  - Totem: Debbie Does Dallas
- Misc
  - My Random App               [ Internal Audio ]
  - My Other App                [ USB Sepakers ]


Would solve that problem, but it would take control away from users too.

Bearing in mind that the "Misc" pseudo-role above (for the "has no role"
case) is likely something that we ultimately want to eliminate by
categorising *all* applications appropriately, the big question to ask is:
 Do we want to ever support per-stream device choices?


If the answer is no, then then this is fine. I can re-engineer my work
based on this.

But if the answer is yes (and IMO I think it should be - there is no
reason I can think of to specifically restrict this degree of
flexibility) then I think the solution I suggested works quite well.

It'll take some time to implement but I think it can be achieved with
minimal API churn in terms of module-stream-restore and
module-device-manager. With m-s-m in particular I thing it can be fully
kept as is.

Col


* I am aware that playing two songs at the same time would be horrendous!

-- 

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