[pulseaudio-discuss] Automatically change 'Default device'?

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 17/02/10 02:13 did gyre and gimble:
> On Mon, 15.02.10 17:13, Ng Oon-Ee (ngoonee at gmail.com) wrote:
> 
>>> Wait no longer!
>>>
>>> http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/
>>>
>>> Col
>>>
>> A nice read Colin, thanks.
>>
>> /me also wonders whether all these 'restore' options need to be made
>> much more transparent. At the very least with a checkbox somewhere
>> saying "save per-stream routings". I believe in the simplest use cases
>> (internal laptop speakers or BT headset on the move, USB headset at
>> home), it would be advantageous to be able to specify that stream
>> routings should NOT be saved, but that a device preference should
>> instead be used.
>>
>> Of course, this is up to those who write the code (and I believe the
>> same thing could be achieved by NOT loading module-stream-restore). I
>> know that it would cover about 90% of my personal use-case though.
> 
> My own thoughts about all of this are basically:
> 
> 1) I think it is bad UI to expose the entire history of devices to the
>    user and allow him to rearrange items in there. I am aware that KDE
>    folks disagree with me on this and like stuff like that and Colin
>    is willing to please them.

While I'm not totally signed up to the fact that it's a good idea, it's
also very little effort to support it. This history will continue to
remain a non-core concept so it shouldn't really get in the way.

> 2) We definitely should save the device history for streams, and when
>    it comes to  finding a device for a stream go backwards finding the 
>    newest entry that is applicable and apply it. All of this should be
>    automatic and opaque to the user.

Good.

> 3) If that didn't result in anything try to find a good default by
>    some other means, i.e. by used "intended roles" and stuff like
>    that. Should be automatic and opaque to the user as well.

> 4) The UI would allow the user to fix any setting the system chose
>    and the system will then remember as good as possible.

So intended roles should slot in here? After we've tried to find the
right device for the stream via specific history list?

My immediate thought on this is that m-i-r should be quite forceful
here, but I'm willing to concede the point as I'm not totally convinced
with myself. The reason I say that is that m-i-r is pretty neat with
VoIP stuff and I'd really like it to work, but if e.g. someone uses
VoIP-App+Webcam there is a good chance that they will have manually
moved the VoIP-App input stream to the Webcam Mic. This means that when
they then open a BT headset, only the output stream is moved across, and
the input stream is still stuck on the input. That's maybe fair enough.

The alternative of course is that m-i-r does not actually do any
internal stream moves itself, it just becomes a way to automatically
inject devices into the role-based priority list (aka history) at the
appropriate place. I've not looked at the code recently but IIRC m-i-r
relies on having a specific device that is most appropriate for a given
role. If so, then this approach could work nicely and make the "order of
rule application" logic a bit simpler perhaps (due to it all being in
m-s-r)? I'd suggest the m-i-r logic should be "I've found an appropriate
device for role X. Is device in prio-list for role X? Yes: Noop, No, Add
it in at the top".

The major downside is that m-i-r would then not work without m-s-r and
I'm not sure that's a great idea for embedded/phone people who may or
may not actually want m-s-r? (I think they probably do want m-s-r, but
not 100% sure as I don't tend to think from this perspective very often)
and I could probably relatively easily code m-i-r to detect if m-s-r is
in use and take appropriate action depending on that.

But overall I think you're right on this one.

> I think this is a simple enough scheme. Certainly, the logic in #3
> (especially) might not be obvious to the user, but that doesn't
> matter: we have to default to something, and it's better to pick the
> most likely device in an non-obvious way than pick a completely random
> one.

Well if the m-i-r worked via manipulating the role-based priority list
rather than actually moving streams itself then the UIs would reflect
this. In terms of pavucontrol for example, it would show the device
being used for the role widget (I'd obviously have to add the device
drop down to the rolewidget just like with streamwidget) and for KDE
folks they'd see the priority list automatically change the first time
the device became available, but be able to change it if they like. It
just becomes a way of picking a sensible default once, which I believe
is the ultimate goal.

> As I understood Colin's blog his suggestion mostly differs in that he
> wants apps to get full access to the device history and change it, so
> that what I call the "history" hence becomes more of a "priority
> list".

Indeed. You've not specifically mentioned the fact that I'm really
proposing three priority/history lists (per-app, per-role, default) that
should be checked in order so I'm not sure how signed up you are to that
idea overall, but the general principles at play here are certainly not
much different.

> But uh, while I don't think that would be good idea UI-wise, if that's
> what makes KDE folks happy this should not be a stumbling block to to
> merge both approaches.

Indeed, that's ultimately what I've tried to cater for: making the
system work nicely for both simple UIs (which will be useful on e.g.
phones/embedded systems) and more exposed/user controlled UIs for those
that want it (both Gnome and KDE would, in my book, be considered "more
exposed" than the simplest possible interface, but with KDE being "more
exposed" than the Gnome one is likely to ever be)

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