With enough metadata so we know that the volume change is caused by us pressing a key. This would allow us to report volume changes through an OSD for Bluetooth headsets. <coling> hadess, I wonder if we could send an event to you for notifying when volumes are changed via bluetooth (or just generally, but with sufficient metadata that you can filter out the ones you yourself have triggered etc.) <coling> hadess, this same mechanism could be used to display the OSD with the new volume when plugging/unpluging jacks etc. (I think you are against this idea generally from our discussions in Berlin which is fine, but at least then a neat infrastructure would be there to allow it). <coling> <coling> Or course you can technically already subscribe to sink change and see volume changes but you wouldn't be certain they came from the keys, hence why something a bit different would be needed.
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.
FWIW, this is still a problem. The problem can also be seen without involving gnome-settings-daemon, as the volume level isn't changed in GNOME's Sound panel or pavucontrol when the headset volume level is changed.
There are two separate problems for the two bluetooth profiles. The original report seemed to be about problem 1, but I think you're talking about the second problem in comment 2. 1) If the user changes the headset volume in the HSP mode, PulseAudio will send a notification about changed sink volume, but a client implementing an OSD doesn't know whether it should show a notification or not. This is solvable by sending more informative notifications. 2) If the user changes the headset volume in the A2DP mode, PulseAudio doesn't know that the headset volume changed. With A2DP there are two volume controls that affect the final volume: the volume that PulseAudio applies, and the volume that the headset applies. This is bad user experience, but at least in the past bluetooth simply didn't provide a way to sync the two volumes. I think newer bluetooth versions have added the necessary functionality, but it hasn't been implemented in PulseAudio.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/361.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.