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

[Tanu Kaskinen]

pe, 2010-02-05 kello 15:06 +0000, Colin Guthrie kirjoitti:
> > 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".

Well, those comments didn't really provide use cases. Pallaeon claimed
that he needed per-app granularity, but didn't say why. The statement is
also in conflict with that he basically said that he would want to use
KMix in place of pavucontrol. Since pavucontrol doesn't provide per-app
granularity, I believe the problem with the categories in the system
settings is just that it doesn't show entries for applications that
don't provide roles for their streams, and that accessing the system
settings is inconvenient (a point raised by other commenters).

All the other comments can be understood as wanting pavucontrol's
functionality in KMix (except for Chris's far-out UI vision).

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

I'd like to see concrete use cases.

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

This is exactly what I meant, except that all other roles would be also
shown.

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

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

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

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

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

-- 
Tanu Kaskinen