[pulseaudio-tickets] [Bug 42445] Report events about volume change

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42445

Colin Guthrie <fdo at colin.guthr.ie> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fdo at colin.guthr.ie,
                   |                            |tanuk at iki.fi

--- Comment #1 from Colin Guthrie <fdo at colin.guthr.ie> 2011-11-01 07:43:21 PDT ---
OK, so one of the goals of this would be to report to clients that are
interested about all "HW triggered" changes, not just bluetooth devices.

As g-s-d currently handles the keys and then uses standard API calls to PA to
change the volumes for most normal h/w devices, the fact that the volume change
was "HW triggered" is most of the time unknown to PA.

To combat this, we could simply get g-d-s to add a property to it's client
proplist when it connects that basically means "Please consider any volume
changes I make to have come from HW". That way we can consistently deliver "HW
volume change" events to all clients.

This approach could mean that a system which handles key presses and converts
them to PA API volume change calls could be a completely separate program from
something that displays the OSD. While this may not be needed by g-s-d I think
this is a good design goal.

So far within currently PA infrastructure, we could pass a "client event". This
is available in PA but currently no client events are actually ever sent (as
far as I can see). Client events allow a proplist to be sent across so we could
use said proplist to get all appropriate metadata we need about the volume
change (e.g. which device, whether the change was triggered by hardware or not
etc.) and leave it up to the client to take from it what it wants.

However, it doesn't really seem like quite the right infrastructure component
to do that.


What seems slightly more natural is the subscription interface, as this can be
used to let clients who want to know about such things that a particular device
(or stream or whatever) has changed. Sadly it only allows us to say "this
device (with index n) has changed. It doesn't allow any other metadata to be
passed. Introspection can then be used, to get all the info about said device
in it's current state, but this doesn't really help us track whether the change
was specifically volume or something else, nor whether a volume change came
from h/w or via some other mechanism.

One possibility would be to not use the CHANGE event mask
(PA_SUBSCRIPTION_EVENT_CHANGE) and instead create a new:
PA_SUBSCRIPTION_EVENT_HWVOLCHANGE mask.... this does seem very specific to this
use case tho', and I'd rather the solution was a bit more generic (and it would
be nice to know the volume right when we get the notification, not have to do
the async introspect to get the volume level we need to display which will take
another round trip).


So really we need something better than we have now.

Tanu said he might think of a replacement for the subscription system (perhaps
building such a system on top of the currently unused client events?) which
would be more flexible and allow both the current (quite restrictive)
subscription use case and the newer, more metadata rich mechanism needed for
this.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.