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

[Colin Guthrie]

Yo

'Twas brillig, and Lennart Poettering at 17/02/10 15:18 did gyre and gimble:
>> 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.

I'm beginning to think that you didn't actually grok the plan fully with
this comment. One of the main points I made was that this key
(stream-restore-id) is a fundamentally broken concept.

> 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's not really what I said. I am proposing three priority lists that
are checked *in order* to find a suitable default device. It fully
permits the per-role based setup as you want it, but it *also* supports
per-app - i.e. it caters for both cases and doesn't mask key PA
capabilities.

First you check the *application* list, then if you don't find an
available device (or the list is empty which it would be in the default
case if no pa_context_*_move_*() API calls have been used for that
stream), then you check the "role" list (iff the stream has a role) and
then you check the *default* list (or if you prefer the role list for
the pseudo role "none").

As I stated earlier the concept of using the stream-restore-id for all
applications is IMO broken. When we get all applications providing nice
metadata it becomes impossible to move an *application* to a new device
without affecting all roles. As you pointed out you can move a specific
instance of an application to a new device without affecting another
instance that is currently running at the same time, but when the stream
is recreated (e.g. track change or app restart depending on
implementation) a different device is used. This is IMO not very user
friendly. Imagine someone hits stop and then play in their media player
or just skips a track and it changes device? Really not nice. Any move
should happen when the user triggers something (i.e. hits a button in a
GUI, plugs in a device etc.) not when they do not expect it.

With my approach you *can* change only the "Music" applications with the
appropriate new API call, but likewise you retain full control over
things at a per-application level. Thus it's more flexible and
sacrifices nothing.

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

Yes Rhythmbox and Banshee *could* share the same role-based list but
likewise allowing control of them independently is also useful. e.g. I
may run MythTV or XBMC (video role) via my HDMI (where their display
goes too) but want to run Rhythmbox/Banshee via my local speakers. Such
cases are not totally unheard of. All I'm saying is that we should allow
this to work. The UI you want is still fully possible via the structure
I propose. The logic is just a tiny bit different at the client side:

Instead of:
 pa_context_*_move_by_*();

It is:
 if (stream_has_role)
   ext_pa_context_*_role_move_by_*();
 else
   pa_context_*_move_by_*();

If you want I could even internalise this logic in a user preference in
daemon.conf meaning no external change if appropriately configured but I
personally don't think this is necessary considering how many clients
out there use the move API.

That said, I wouldn't recommend a UI presents it this way anyway. It
should offer a very specific UI to move whole role to a different device.

If the UI does not offer the ability to move streams to a device then
the per-app priority list will never be populated and thus never come
into the equation when deciding where to route a stream.

> Note that this all is for picking good defaults only. Whatever we pick
> by default, the user can still manually override. 

That's exactly what is *not* possible right now! Control is taken away
from the user and the way things operate is inconsistent and thus
confusing. If an application provides metadata it operates in one way
and if it doesn't it operates in another. As a user I don't know if an
application provides a role or does not. Even when all applications do
provide a role, as a user I don't always want to move everything from
that role to the new device. If the UI presents me with a widget for a
specific application and has a menu/dropdown/whatever to move to another
device I expect to be able to move just that application.

If you do ultimately insist on this behaviour then I'd strongly
recommend that any client that offers stream moving capabilities be
updated to not show the move option for any streams with a role and
provide a different way to move whole roles to new devices instead.
Either that or the client should make it very clear to the user that
they will be moving all music streams and not just this one. This would
at least make it clear to users what the hell was going on. Regardless,
this is still externalising what should be internal logic to the clients
- they'd have to check if m-s-r was loaded before calling what should be
a core API so they can present the UI correctly.

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

You don't really support it because the stream will only play on their
desired device until the track changes. That's hardly what I'd call
"supporting" such a use case.

But I don't see why we can't support this. The amount of effort required
is relatively minimal and coded at a high level and I'm already
volunteering to do the work. I really don't see the logic of cutting off
some genuinely useful functionality.

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

There wouldn't be different keys, the whole concept is not based around
storing a stream-restore-id anymore, it's gone, it's not there, disappeared.

It's based around a three tiered list of priorities checked in order.
The APIs to work with these lists have pre-defined, consistent results.


This whole thing can be summed up with two points:

 1. The value of stream-restore-id causes API calls to work in an
inconsistent manner. Clients will need to grok a lot of information and
re-implement core logic in order to present the user with a UI that is
clear and makes it obvious what is going to happen.

 2. Streams which share the same stream-restore-id will *not* be moved
when one of them is updated, but *will* use the new preference at the
next opportunity - the next opportunity being: 1) when a track is
skipped 2) play/stop hit 3) application restarts or 4) the stream
restore database entry is updated by a client. This is a pretty alarming
thing to happen when you don't expect/trigger it.


So really I'm not arguing that your end goal is invalid, just that the
implementation that relies on a single stream-restore-id and ultimately
triggers inconsistent results from API calls is thus broken by design.

I'd much rather expose APIs (optional ones via extensions rather than
core) that act and behave in a consistent manner. It ultimately
simplifies the clients and keeps the routing logic very clear and nailed
down.

Hope I've managed to explain things better this time.

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