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

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 06/02/10 08:38 did gyre and gimble:
> pe, 2010-02-05 kello 15:06 +0000, Colin Guthrie kirjoitti:
>> 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 ]
> 
> This is exactly what I meant, except that all other roles would be also
> shown.

Yeah, I meant to include them but I was lazy and couldn't remember them
all off hand :p

>> Would solve that problem, but it would take control away from users too.
> 
> How would it take control away from the users? Wouldn't my proposed
> interface provide exactly the same functionality as pavucontrol does
> today? Or maybe I'm misunderstanding, and you meant that compared to
> your proposal, my proposed UI would take control away.

Sorry I don't mean it would be less featureful than today's pavucontrol,
just that we'd basically be lopping off a large chunk of PA's
flexibility from the user due to the routing system in the server (and
by extension via the UI's provided).

>> 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?
> 
> Until a convincing use case is presented, I will answer "no" for
> mainstream UIs.

There are always going to be use cases I reckon - e.g. playing a movie
via HDMI for someone else while you work and perhaps play a movie
locally too.


> * except that I don't think it handles properly the case where an app
> doesn't first have a role and then one day the app is updated and the
> role is assigned from then on. In that situation the per-app priority
> list is populated, but the role priority list should be used. The
> solution would be to store information about whether a role has been
> assigned to an application before and if not, then when the role is set
> for the first time, the per-app priority list should be cleared.

This is OK, if an application has a priority list and it's acquires a
role via some means (env var, app update, .desktop tweak etc.) then this
can be "fixed" by selecting the "Automatic" option in my proposed UI for
that specific application. This would then fall back to using the
Role-based routing and the user knows what's going on and is not confused.


> I don't actually oppose your server-side proposal*, I only oppose making
> per-app control available in mainstream UIs, for the reason that moving
> roles is better in a vast majority of cases, and adding the possibility
> for per-app moving adds clutter and confusion (although I guess in KDE
> philosophy that's not as big deal as in Gnome philosophy).

I don't think per-app moving needs to add clutter in a suitably designed
UI. I'm not necessarily against ommiting this capability from e.g. the
Gnome tools - I just want to ensure it's physically possible for those
users who want it.

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