Bug 507212 - Pulseaudio Volume Control (pa-applet) wakes up all audio devices when opening
Summary: Pulseaudio Volume Control (pa-applet) wakes up all audio devices when opening
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Audio Volume widget (other bugs)
Version First Reported In: 6.4.3
Platform: Arch Linux Linux
: NOR minor
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-07-18 21:29 UTC by z411
Modified: 2025-12-02 00:32 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description z411 2025-07-18 21:29:48 UTC
SUMMARY
Plasma's audio volume widget wakes up all audio devices when opening.

I have 4 audio devices, and 2 of them are USB DACs that power off (or enter a stand-by mode) after a few minutes of inactivity. When I open the volume control applet, it wakes them all up even though I haven't selected any yet.

STEPS TO REPRODUCE
1. Click the audio volume widget on the Plasma panel

OBSERVED RESULT
The widget should just open and list the devices, nothing else. But it wakes up all audio devices as well.

EXPECTED RESULT
The widget should just open without talking to the audio devices at all unless I select one and/or pressed the volume slider so it makes a sound.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux x86_64 updated to 20250718
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Audio backend: pipewire + pipewire-pulse

ADDITIONAL INFORMATION
It can be seen using qpwgraph that opening the volume applet a connection is opened to all audio devices in the system. I assume this is done so a sound can be played when moving the volume sliders. The problem is that this wakes up all audio devices that are in a standby state. It should only open a connection to them when necessary (after pressing the volume slider of the interface, or actually switching to the interface) and only with the interface in question, not all of them.

So far to me this only happens in KDE Plasma. I haven't observed this behavior in other DEs or operating systems yet. The behavior I've seen is that an interface is woken up only when switching to it (or actual sound needs to be played through it).
Comment 1 z411 2025-07-19 16:03:54 UTC
Additional: I thought disabling "Play audio feedback for changes to audio volume" in the sound options would serve as a workaround but it doesn't; the audio connections are still being made and wake the devices up.
Comment 2 Harald Sitter 2025-07-21 05:21:11 UTC
There's a VU meter in the volume bar that requires listening in on the output. The fact that this wakes up the device seems more like a problem in alsa or pipewire since we don't actively produce any new output.
Comment 3 z411 2025-11-04 05:08:22 UTC
Right. I asked the guys over at PipeWire but I don't think I'll be getting a reply anytime soon.

The Qt theme I use makes the VU meter invisible anyway so as a workaround I patched the applet so it doesn't open audio streams. It obviously disables the VU meter but it doesn't wake up my audio devices.

If anyone reading needs this, just comment out the createStream() call inside the setTarget method in src/volumemonitor.cpp (line 84 at the time of writing).
Comment 4 Harald Sitter 2025-11-04 10:25:50 UTC
Unfortunate. I wonder if there's benefit to be had from an option that disables the meters. There have also been problems with bluetooth profiles switching around because of them.
Comment 5 z411 2025-11-05 19:49:37 UTC
Mhm, I think the VU meter is fine and you're right to observe that not sending audio to the device shouldn't wake it up. While an option to disable it could be useful in some cases, I think it'd be only there as a workaround for issues that shouldn't be caused by a mere VU meter.

If I remember correctly, the VU meter in Windows didn't wake up my devices so I don't think it's some kind of hardware limitation but indeed an implementation quirk somewhere along Linux's audio chain.
Comment 6 pav 2025-11-12 19:25:15 UTC
The pa-applet probably should set PA_STREAM_DONT_INHIBIT_AUTO_SUSPEND when it is monitoring sinks/sources. 

See https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/commit/1f58c43347c8fe36b88165064ba8196b477525ef for pavucontrol.
Comment 7 Bug Janitor Service 2025-11-13 06:23:47 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-pa/-/merge_requests/385
Comment 8 z411 2025-11-13 15:04:15 UTC
Thanks for noticing - I'm not knowledgeable about PulseAudio workings but wouldn't this let the device go to sleep, but still wake it up whenever it opens?
Comment 9 Harald Sitter 2025-11-14 06:58:58 UTC
Git commit 7000439d260199bd49d9fd9b6bf2cc62d5b1f431 by Harald Sitter.
Committed on 14/11/2025 at 06:55.
Pushed by sitter into branch 'master'.

volumemonitor: don't inhibit auto suspend of device

the volume monitor stream is entirely passive and only observes what
other streams are doing. as such it has no business holding up auto
suspend

M  +1    -1    src/volumemonitor.cpp

https://invent.kde.org/plasma/plasma-pa/-/commit/7000439d260199bd49d9fd9b6bf2cc62d5b1f431
Comment 10 Harald Sitter 2025-11-14 07:02:11 UTC
Git commit 0af59f92acbe817e55d053c426c97b71a0aa1ad1 by Harald Sitter.
Committed on 14/11/2025 at 06:59.
Pushed by sitter into branch 'Plasma/6.5'.

volumemonitor: don't inhibit auto suspend of device

the volume monitor stream is entirely passive and only observes what
other streams are doing. as such it has no business holding up auto
suspend


(cherry picked from commit 7000439d260199bd49d9fd9b6bf2cc62d5b1f431)

Co-authored-by: Harald Sitter <sitter@kde.org>

M  +1    -1    src/volumemonitor.cpp

https://invent.kde.org/plasma/plasma-pa/-/commit/0af59f92acbe817e55d053c426c97b71a0aa1ad1
Comment 11 Nate Graham 2025-11-14 18:12:59 UTC
Unfortunately the fix had to be reverted as it caused a memory leak that is still under investigation.
Comment 12 z411 2025-11-15 04:09:31 UTC
Thanks for your work. I can confirm the patch fixed this issue completely, but the regression was unfortunate. I hope it turns out to be a simple fix.