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

[Lennart Poettering]

On Wed, 17.02.10 09:26, Colin Guthrie (gmane at colin.guthr.ie) wrote:

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

I don't think the user should see any of the automatic stuff. He
should see his own configuration, that's all. And as mentioned only
the most recent configuration, not all of it.

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

You can always come up with use cases where one of the possible
solutions chooses the wrong device. But don't forget two things: after
the user corrected this once, and with the history stuff it will stay
corrected for the future. And this case is kinda nichey.

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

I am not convinced this is a good idea. User configuration should stay
user configuration and should take precedence over every kind of
automatism. Also, patching user configuration automatically sounds like
a bad idea to me.

I also like to keep things independant of each other.

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

Yes, I am pretty sure that keeping m-s-r and m-i-r seperate is very
useful for embedded folks where a UI for switching streams mit be
missing and where hence automatic selection is crucial and manual
configuration impossible.

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

This is actually a point I am firmly against. This would basically
mean that the key we read data from the database with might be a
different one from the key we store data in the database with.

Also, just think of the use cases. if I look at my setup here: i have
a bt headset for voip, internal laptop speakers for event sounds and
my hifi via spdif for music/video. That means the output ports I
choose by the role of the audio streams I play. However, you are
suggesting to save/restore stuff primarily per-app. That would mean
Rythmbox and Banshee would get saved/restored devices
independantly. But that simply makes no sense. I am pretty sure you'll
find very few people on this world who have two hifi decks, one for
the stuff they play with banshee and another one for the stuff they
plan with rhythmbox.

Note that this all is for picking good defaults only. Whatever we pick
by default, the user can still manually override. So even if there in
fact do exist weirdos who want to pass rb audio to hifi #1 and banshee
audio to hifi #2, they can still configure things manually and it will
work. Of course, we won't automatically save/restore these settings
for them, but I can live with leaving those weirdos out in the
cold. They are not the common case, they are the exception.

So, I really don't see the use case here, and I am concerned about
using different keys for the db reads and writes.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4