Bug 493962

Same here, Arch Linux, Plasma 6.1.5.

Works normally after reboot, but at some point just starts to happen. Aside from volume only changing at most by 5%, the volume popup is sometimes yellowish.

First noticed it yesterday. However, Plasma and KDE applications have not been updated since the middle of September. Potentially relevant updates a few days ago: Pipewire 1.2.4 -> 1.2.5, Qt 6.7.2 -> 6.7.3.

Oh, and Linux 6.10.10 -> 6.11.1.
I'm not absolutely sure, but I think I first encountered the issue after the kernel update, and not during the 3 or 4 days between Pipewire/Qt updates and kernel update.

When I was on Fedora 40 and KDE 6.1.5 it was OK. Started when I have updated to Fedora 41 beta with KDE 6.2 beta.

Just checked on an old test notebook and no problem here for Fn-Volume.

Operating System: Fedora Linux 41
KDE Plasma Version: 6.1.90
KDE Frameworks Version: 6.6.0
Qt Version: 6.7.2
Kernel Version: 6.11.0-63.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i3-6006U CPU @ 2.00GHz
Memory: 11.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
Manufacturer: LENOVO
Product Name: 81B6
System Version: Lenovo V320-17ISK

I strongly suspect that a regression in PipeWire or the kernel has caused this.

Is there any way to restart the audio volume control? Restarting plasmashell doesn't seem to help.

Booted into Fedora 41 beta yesterday. And the volume change now is working OK. 

@Sebastian E., try in terminal 
$ systemctl --user restart pipewire.service

Created attachment 174365 [details]
video

Just got this problem, made a video. Sorry, it is a bit long, could not find a way to stop the recording.

What's the problem? The keys seem to be working?

It is stuck in 95%-105% (real volume is 40%) and does not change the volume.

The tray icon works fine. But when I hover the tray icon and move the mouse wheel it again shows 95%-105% and does not change the volume.

What does 

pactl get-sink-volume @DEFAULT_SINK@

say?

$ pactl get-sink-volume @DEFAULT_SINK@
Volume: front-left: 20560 /  31% / -30,21 dB,   front-right: 20560 /  31% / -30,21 dB,   lfe: 29491 /  45% / -20,81 dB
        balance 0,00

A possibly relevant merge request was started @ https://invent.kde.org/libraries/pulseaudio-qt/-/merge_requests/45

Git commit cb8bea910475a0822d39fa8c1ccd6fe3d1e795d0 by Harald Sitter.
Committed on 03/10/2024 at 22:43.
Pushed by sitter into branch 'master'.

debug volume setting

Without this it's impossible to know which object is being manipulated

M  +1    -0    src/sink.cpp
M  +1    -0    src/sinkinput.cpp
M  +1    -0    src/source.cpp
M  +1    -0    src/sourceoutput.cpp
M  +2    -0    src/streamrestore.cpp

https://invent.kde.org/libraries/pulseaudio-qt/-/commit/cb8bea910475a0822d39fa8c1ccd6fe3d1e795d0

@Eugene Savitsky: I already tried restarting pipewire.service as well as pipewire-pulse.service, but it doesn't help. In fact, it might trigger the issue.

@Harald Sitter:
I think only logging the name might not be enough as there seem to be duplicates involved.

I tried the following experiment multiple times:
1. Reboot
2. Login
3. Start Konsole
4. Run: systemctl restart --user pipewire.service pipewire-pulse.service
5. Open the audio volume popup to check what devices are listed.

There are two possible outcomes:
1. The expected devices are listed and I can mess around as much as I want (see 2.), it keeps working correctly.
2. The devices are duplicated. Restarting Pipewire again won't create more duplicates, unless I change the output profile of a device beforehand (using pavucontrol, which I prefer). Then one of the duplicates will become the new output and another restart of Pipewire will create more duplicates. `pactl list sinks` only shows the expected sinks.

Also, devices sometimes have different names, i.e. "HDMI 0" instead of the display name, or "Line out" instead of "ALC1220 Analog" (I guess the latter depends on whether HDMI output is enabled or off).

I'll attach two screenshots.

By the way, I also encountered the issue with the volume keys after downgrading to Pipewire 1.2.4 (and unfortunately didn't check for duplicates), but the experiment above was done after upgrading to 1.2.5 again.

Created attachment 174388 [details]
Audio volume popup with duplicated devices

Created attachment 174389 [details]
Audio volume popup with duplicated devices

Created attachment 174397 [details]
No multiple devices

I do not have multiple devices... And still I cannot change volume by keyboard or mouse wheel hovering volume icon.
I do not restart the PC just in case I need to make some logs.

Does it always happen? For me volume keys are working normally until they suddenly don't. Volume is then stuck between what it was +/- 5%.

For me it started after I updated to Fedora 41 beta & KDE 6.2 beta.

After restart it works and after some time it is stuck in 95-105%. The volume change in tray works fine.

Updating from Fedora 40 to 41 also involves updating from Kernel 6.10 to 6.11.1. I'll try downgrading my kernel when I find a reliable way to reproduce it. It's quite random and I don't play audio that often.

What happens when you right click the applet in the tray and enable 'show virtual devices'? Do you see more devices in the applet? Is one of them possibly in the ~100% range?

Created attachment 174403 [details]
virtual devices enabled

Nothing suspicious.

Created attachment 174404 [details]
settings with duplicate devices

In settings I have found a ghost devices, that duplicates same sound card and monitor (monitor does not have speakers).

I cannot select it the second device, but this device has the volume control.

What's the output of `pactl list` right now?

I can answer only on Monday evening, since I'm away from home now.

And Teamviewer/Anydesk/Rustdesk still (if ever) cannot be used under Wayland to do it remotely. :-/

@Eugene:
You posted the specs of an "old test notebook" where you do *not* have the issue. I'd like to know the specs of the affected workstation (the video looks like there are some professional audio applications involved, so I'd guess its CPU is on the higher end).

@all:
I'm asking because there seem to be duplicates involved (i.e. the state of pulseaudio-qt gets out of sync with PipeWire), and there seems to be a race condition at initialization time which determines whether duplicates can occur or not.

I only have little experience with C++/Qt, but I'd dare to suggest that the race condition might be there:
https://invent.kde.org/libraries/pulseaudio-qt/-/blob/cb8bea910475a0822d39fa8c1ccd6fe3d1e795d0/src/context.cpp#L265

Either connectToDaemon() succeeds immediately, before the constructor finishes and all signals/slots are connected—or it's called later (maybe from another thread) after the constructor has finished (or maybe even in-between). That depends on whether the D-Bus service is already registered (i.e. pipewire.service and pipewire-pulse.service are up) when that code is executed.

I experimented a bit further, trying to ensure either condition, though not enough to make a call. However, I think things go wrong when PipeWire is already up, which is more likely with more CPU cores (I've got an AMD 5950X). Performance improvements with newer kernels might also tip the scale, but at first glance those coming with kernel 6.11 don't affect my CPU.

Uhm... not really. I only tested each case twice yesterday, and got the presumed result each time. Today I repeated each case 5 times and only got the presumed result 3 out of 5 times. So it's something else. Or maybe my method didn't work. I started PipeWire before launching Plasma from the console for one case, and added ExecStartPre=/usr/bin/sleep 4 to both pipewire.service and pipewire-pulse.service for the other case.

Nevertheless, since I noticed this phenomenon, I always reboot until I get a good state, and haven't had issues with the volume keys since.

By the way, only the volume popup is affected by duplicates. In system settings I only got duplicates once while they where open, and they disappeared after closing and reopening it.

Desktop PC:
Ryzen 5800X
Sound Blaster Z

The "professional software" in my video is https://flathub.org/apps/me.timschneeberger.jdsp4linux

I'm trying to move from Windows (Win 11 cannot put taskbar to the left, so it is a no go for me) and playing with Linux on various distributions and hardware to see if all works as I want/need. I've installed openSUSE KDE on a daily Lenovo notebook alongside Windows 10 and the sound quality is awful (sounds flat as gramophone), compared to Windows and https://flathub.org/apps/com.github.wwmm.easyeffects cannot change it. 

I have made a thread: https://forums.opensuse.org/t/bad-sound-quality-linux-vs-windows/179032/47
Then I realized, that on desktop the sound is same as bad. Inspecting the Windows driver for Lenovo I found, that there are XML files with sound tweaks (surround, equalizer) for all Lenovo notebooks (as the Sound Blaster drivers and software does for Windows). Someone suggested I have to install JamesDSP to try if that helps. But that did helped only for 15% maybe.

I have installed JamesDSP after the problem in this bug accrued.

BTW In the desktop (Fedora 40+) I have a problem with the the sound, that after waking PC from sleep the sound is not working and I have each time to restart Pipewire by:
$ systemctl --user restart pipewire.service

It started about KDE 6.1.1 update. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2298658

Created attachment 174497 [details]
pactl list output

(In reply to Harald Sitter from comment #25)
> What's the output of `pactl list` right now?
Here is the output.

Just upgraded Fedora 41, new kernel, KDE 6.2 final.

Operating System: Fedora Linux 41
KDE Plasma Version: 6.2.0
KDE Frameworks Version: 6.7.0
Qt Version: 6.7.2
Kernel Version: 6.11.2-300.fc41.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 31,2 GiB of RAM
Graphics Processor: AMD Radeon RX 480 Graphics
Manufacturer: ASUS

Created attachment 174498 [details]
sound devices after restart

Created attachment 174499 [details]
pactl list after restart

I have the suspicion that we actually manipulate the volume of the easyeffects sink. We will need a new pulseaudio-qt release so we can figure things out.

Unless. Are you able to build from git perhaps?

If I get step-by-step manual, I can.

In a terminal run the following

run0 dnf install -y git
run0 dnf builddep -y pulseaudio-qt
git clone https://invent.kde.org/libraries/pulseaudio-qt.git
cd pulseaudio-qt
cmake -S . -B build -DBUILD_WITH_QT6=ON
cmake --build build
LD_LIBRARY_PATH=`pwd`/build/bin QT_LOGGING_RULES=org.kde.pulseaudio=true kded6 --replace

Then trigger the volume keys.

It should print messages containing "Changing volume of Sink...". Those I am interested in. To restore the default behavior simply logout and in again.

I have to do it when I have the bug faced, right?

No, it needs to be done in preparation.

All commands except the last one are for building the modified pulseaudio-qt binary (i.e. with extra logging). You only need to do that once, unless some other dependencies are updated via Fedora - then you might need to rebuild that binary (which is a library).

The last command restarts the main KDE daemon, while also instructing it to use the modified library and output all relevant logging by setting environment variables beforehand. Note that `pwd` is substituted by the current directory, so replace it by or cd into the build directory before running the command again.
Also note that the last command got inauspiciously wrapped in the email notification but is correctly displayed in the browser. It begins with LD_LIBRARY_PATH and ends with --replace.

I have it stuck inbetween 80-90%

org.kde.pulseaudio: Changing volume of Sink "alsa_output.pci-0000_07_00.0.analog-surround-21"  to  24248
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  262 "Properties"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  264 "Volume"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  268 "ChannelVolumes"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  273 "CardIndex"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  274 "Ports"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  275 "ActivePortIndex"
org.kde.pulseaudio: Changing volume of Sink "alsa_output.pci-0000_07_00.0.analog-surround-21"  to  20972
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  262 "Properties"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  264 "Volume"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  268 "ChannelVolumes"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  273 "CardIndex"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  274 "Ports"
org.kde.pulseaudio: PROPERTY CHANGED ( 1 ) ::  275 "ActivePortIndex"

Correction: before I made the manual it was stuck inbetween 80-90%. After I run all commands now it is working again...

Maybe we are in luck and it happens again now that you have it running in logging mode ;)

If not, you'll probably want to run

cd pulseaudio-qt
LD_LIBRARY_PATH=`pwd`/build/bin QT_LOGGING_RULES=org.kde.pulseaudio=true kded6 --replace

after every login so the logging mode is enabled.

OK, now I have it run all the time. Hope for the problem will occur.

Created attachment 174610 [details]
log screenshot

After waking PC from sleep up I restarted pipewire (systemctl --user restart pipewire.service), since sound crad does not work with it and got the problem (80-90%).

Created attachment 174611 [details]
Easy Effects not responding

And BTW, after pipewire restart I cannot launch Essy Effects.

Created attachment 174612 [details]
sound volume  works as expected

Tried to change volume by hovering the icon in tray and got a crash.

           PID: 3680 (plasmashell)
           UID: 1000 (ezh)
           GID: 1000 (ezh)
        Signal: 11 (SEGV)
     Timestamp: Thu 2024-10-10 14:49:55 EEST (1min 20s ago)
  Command Line: /usr/bin/plasmashell --no-respawn
    Executable: /usr/bin/plasmashell
 Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/plasma-plasmashell.service
          Unit: user@1000.service
     User Unit: plasma-plasmashell.service
         Slice: user-1000.slice
     Owner UID: 1000 (ezh)
       Boot ID: 4644f0ea139b4df7a3eff69b22162fcc
    Machine ID: 6480da28f8384facb713589533beb2c6
      Hostname: fedora
       Storage: /var/lib/systemd/coredump/core.plasmashell.1000.4644f0ea139b4df7a3eff69b22162fcc.3680.1728560995000000.zst (present)
  Size on Disk: 41.4M
       Package: plasma-workspace/6.2.0-2.fc41
      build-id: a5ea5cd60edec877170a37390f743634c4ef4f23
       Message: Process 3680 (plasmashell) of user 1000 dumped core.

Is there's way to see a crash submission number to post it here?

Looks unrelated. What's the output of the kded command though?

You mean the crash is unrelated?

Yes

After all updates I still have this issue.

I still haven't seen output of the kded command I think.

Sent 10.10.24:
https://bugsfiles.kde.org/attachment.cgi?id=174610

Ah! So we definitely end up manipulating the easyeffects sink. What happens is that we change the volume. Easy effects changes it back. We change the volume. Easy effects changes it back. … 

I guess the next step is figuring out why exactly we end up with easyeffects as the preferred sink. Which may actually have to do with the fact that your pulseaudio context broke (which would be an upstream issue)

You mean, Pipewire, that I have to restart after PC going to sleep?

Do I have to fill a bug against Pipewire?

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Yeah, it's not normal to forcefully restart pipewire after sleep ;)

It's also not normal for the volume popup to show duplicates after restarting PipeWire, while pactl shows no duplicates.

Yeah, I know, it's a wild guess, but my intuition tells me that this issue can be fixed with an explicit ConnectionType (https://doc.qt.io/qt-6/qt.html#ConnectionType-enum) somewhere.

I have filled a bug: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4362

So far the data points at the shortcut handling context not correctly re-establishing connection to the pulseaudio daemon. For the applet we've solved this by giving it a UI when that happens. It is a bit concerning that this happens with some regularity to the shortcut system too though. That said, some friction is to be expected if the daemon just disappears out of the blue.

A possibly relevant merge request was started @ https://invent.kde.org/libraries/pulseaudio-qt/-/merge_requests/47

Git commit d43c9efac85af372d1ede9503ce19bb1f0bc0b8c by Harald Sitter.
Committed on 24/10/2024 at 15:00.
Pushed by sitter into branch 'master'.

context: correctly initialize try count

this was previously entirely unint'd leading to a roll of the dice if it
was 0 or not and consequently breaking the context auto connection
feature when it was >5

possibly the root cause behind the context sometimes not
auto connecting

M  +1    -1    src/context_p.h

https://invent.kde.org/libraries/pulseaudio-qt/-/commit/d43c9efac85af372d1ede9503ce19bb1f0bc0b8c

I did not saw this issue for a while and thought it was fixed, but today the problem reappeared.
KDE 5.2.3

I'm not able to reproduce this on git-master. When I press the volume keys on my laptop's keyboard, the volume is changed.

Can you see if you can still reproduce this with Plasma 6.3.5 or later? If you can, please set this back to REPORTED. Thanks!

I do not use Linux very often, but have not seen this problem for a long time.

(In reply to Eugene Savitsky from comment #69)
> I do not use Linux very often, but have not seen this problem for a long
> time.

Thanks for following up, this is good news.

(In reply to Sebastian E. from comment #62)
Sebastian, are you still seeing this bug on your system?

🐛🧹 ⚠️ 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!

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.