Bug 456310

Summary: Keyboard volume control keys don't change the volume of the default sink
Product: [Plasma] plasmashell Reporter: lucasrizzini <lucasrizzini>
Component: Audio in generalAssignee: Plasma Bugs List <plasma-bugs>
Status: REPORTED ---    
Severity: normal CC: andrej.halv, andy, bugs.kde.org, eduardo.cruz, gudvinr+kde, isma.af, jack, mail, nowrep, rad.n, rakijaisthebest, sitter, tamas
Priority: NOR    
Version: 6.2.4   
Target Milestone: 1.0   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Video showing the mentioned behavior
Bug showcase
showing the audio systemtray window with selected *default* source

Description lucasrizzini 2022-07-04 09:37:03 UTC
Created attachment 150383 [details]
Video showing the mentioned behavior

I have two audio outputs, HDMI and the motherboard P2 and Isetting up a virtual/null sink for the simultaneous output experience. After creating a new virtual/null sink and setting it as the default, when I use my keyboard volume control keys, it won't control the volume of the new default sink. I attached a small video showing that behavior.



STEPS TO REPRODUCE
1. Create a new sink.
2. Set it as the default.
2. Change the volume using your keyboard media keys.

OBSERVED RESULT
In my case, only my HDMI output sink is controlled, unless I play something and manually change the volume of the default sink. Only then my keyboard volume control keys control the default sink volume. 

EXPECTED RESULT
Having my keyboard media key controlling my default sink no matter what, since it's the default sink.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: Plasma 5.25.2
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.5

Reddit post about it -> https://www.reddit.com/r/kde/comments/vqsc1s/keyboard_volume_control_keys_dont_change_the/
I found some old similar bug reports, but
Comment 1 lucasrizzini 2022-07-04 09:38:09 UTC
Fixing the last line: 
I found some old similar bug reports, but none to this specific scenario.
Comment 2 Andrej Halveland 2022-10-29 15:53:41 UTC
I have the exact same behaviour, although I noticed that when the virtual sinks are not connected to anything the volume seems to adjust just fine, but If I load my Carla project with several EQs and things like that, then it starts to misbehave...

I experience this bug on multiple of my computers.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: Plasma 5.26.2
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.6
Comment 3 Andrej Halveland 2022-10-29 15:57:22 UTC
Created attachment 153299 [details]
Bug showcase

Also forgot to mention... If I close the audio source (mpv in the video), I once again can't adjust the volume by using volume keys, as seen at the end of the video.
Comment 4 andy 2022-11-07 21:30:03 UTC
I just switched from pulseaudio to pipewire-pulse and now experience this issue when I didn't before. I'm on arch linux plasma 5.26.2

I have 5 audio sinks. When I used the vol up/down buttons on keyboard, it was adjusting the volume of the first sink, which was not the currently selected/toggled sink. Per the OPs reddit post/video I tried the workaround - to play some audio and then manually change the volume first. After this the keyboard vol up/down keys respect the correct sink.
Comment 5 andy 2022-11-07 21:31:13 UTC
also not sure if it matters but I'm using `pactl load-module module-combine-sink` for a "simultaneous outputs" solution
Comment 6 Eduardo 2023-05-31 18:43:24 UTC
I suffer a lot from this issue. I use pipewire with a virtual sink, and I use Carla with some LSP - Linux Studio Plugins - equalizer/crossover on top of the virtual sink routing to the real sink.

My default sink is the virtual sink, and that's the one that should have the volume being controlled. However, most of the times, the applet changes the volume of the real sink. Just like the OP's video. But for me it's somewhat random, sometimes it works correctly, sometimes it doesn't. Regardless of something being played back or not.

I've looked into the code, in this file https://invent.kde.org/plasma/plasma-pa/-/blob/master/src/pulseaudio.cpp there is a method called "findPreferredSink()" in line 271.

From reading the code, I understand there are 2 distinct concepts: "default sink" and "preferred sink. "Default sink" is the selected sink on the applet's UI, and "preferred sink" is a guess of what sink should have the volume controlled based on the playback state. For instance, if "sink A" is the selected "default sink" in the UI but it happens to not have any playback going on, while another "sink B" does have playback going on, then the code would select "preferred sink" as "sink B", not "sink A", and volume changes would affect "sink B" and not "sink A". That seems to be with the best of intentions, however something is not working correctly in the case of virtual pipewire sinks.

I don't see any obvious logic error by reading the code and running it mentally. But I haven't managed to debug it since I don't know of an easy way to compile and run this applet and see some sort of console output.

Simple fix would be to just disregard this "preferred sink" concept at all and just always adjust the volume of the selected "default sink". However that feature is there for 7 years and I guess most KDE mantainers would not agree to delete an already deployed feature like this.

So... maybe someone can properly debug this code and find the bug? Perhaps pipewire is guilty of not reporting the correct state of its devices, if we can debug and show that it is the case, we should file a bug report in pipewire. Or perhaps there is a logic bug in this code that I'm not seeing now.
Comment 7 andy 2023-05-31 20:32:05 UTC
I keep experiencing weird stuff with pipewire and the selected device in the volume control, maybe it's related.

Like opening a video with mpv, and it randomly choosing to play audio either from the first device in the list (currently muted and unselected), or the currently active/selected one with the radio button selection. I was originally opening and closing mpv multiple times over until I got audio, thinking it was an mpv problem, but then I found not getting audio was because of it randomly picking the muted&unselected device

I've also discovered the hamburger menu's "Play all audio from this device" and "Record all audio from this device" which is confusing because clicking that does NOT change the radio button position. So what do the radio buttons to select a device actually do then?
Comment 8 Ismael Asensio 2023-08-22 22:43:02 UTC
*** Bug 473493 has been marked as a duplicate of this bug. ***
Comment 9 Sqaaakoi 2023-09-16 12:24:30 UTC
I've also been experiencing this recently. I am using Pipewire and my config includes a virtual surround sound sink for my headphones. The issue has only been occuring since this virtual sink was added. I am not sure what defines the "preferred sink", however I can note that all the devices it chooses to fallback to are connected via USB (Headphones, speakers) or is the virtual sink I have created. Also, those devices are the only devices I actively select to use as the default sink.
Comment 10 fanzhuyifan 2023-11-05 05:21:05 UTC
*** Bug 476519 has been marked as a duplicate of this bug. ***
Comment 11 Stefan Krüger 2024-05-09 06:41:26 UTC
i see a very similar pattern:
i have a *combined sink* (to split up my system audio to multiple sources)
and if my audio player is selected to play directly on my usb audio device the key-shortcuts / systemtray AudioVolume thing does not show / handle the right device..
if i switch the audio player app and reslecte the default in the widget it works with the combined one.
i would like to use the shortcuts for the real usb audio  device...
if i then select the USB-Audio Device as *default* and then use application tab and change the audioplayer to the combined device it works as i like it..
Comment 12 Stefan Krüger 2024-05-09 06:44:09 UTC
Created attachment 169332 [details]
showing the audio systemtray window with selected *default* source
Comment 13 Harald Sitter 2024-10-03 12:31:24 UTC
Can someone please provide commands to replicate an affected setup?
Comment 14 Stefan Krüger 2024-10-03 17:30:41 UTC
my setup is effected.
but for me it is currently random and i have no idea how to reproduce it reliable.. sorry.
Comment 15 Bug Janitor Service 2024-10-18 03:47:47 UTC
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 16 andy 2024-10-23 01:40:05 UTC
I think this is a reproducer, let me know if it (doesn't) works for you:

(with pipewire and pipewire-pulse installed)
- Run `pactl load-module module-combine-sink` to create an aggregate device
- Try to select the "combined" device in task manager > audio volume (but if like me, you'll find it's not in the list of devices in this widget, leading to the next step:)
- Instead go to System Settings > Sound and select the "combined" device (click radio button to make it default playback device)
- Click the test button and confirm it outputs audio to all output devices
- Use the global volume control keys and see if it changes the new default sink

The result is it changes the volume of the old sink and not the new "combined" sink. Also we don't see the new device in the task manager volume control (this may be new bugs... I've been noticing I have to `systemctl --user restart pipewire-pulse` sometimes to refresh devices in the volume control widget, but in this case with the pa module it will not survive the service restart. In the past I definitely used the module-combine-sink and it would show up in the volume control widget.).


Operating System: Arch Linux
KDE Plasma Version: 6.2.1
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.6.57-1-lts (64-bit)
Graphics Platform: Wayland
Comment 17 andy 2024-10-23 01:47:25 UTC
oh, disregard the thing about it not showing up in the volume control widget. I found it hidden behind hamburger menu > show virtual devices.

Selecting the "combined" device from the volume control widget still seems to show the same effect of the volume control being synced to the wrong device.

Also very weird, the original default device is my speakers and one of the extra devices in the aggregate is headphones. When I press volume up many times in a row, I hear one of the "volume up sound" in the headphones and then subsequent ones through the speakers, and at the same time I see connections flying around in qpwgraph while this happens.

And there's something weird with the devices listed in the volume control widget. I've done ` systemctl --user restart pipewire-pulse` a few times and it seems to not drop previous devices. I see "combined" listed 3 times, and some of my other output devices have duplicate entries, which is not consistent with what I see in qpwgraph.