https://bugs.kde.org/show_bug.cgi?id=522569
Bug ID: 522569
Summary: Opening the Audio Volume tray applet triggers rapid
sink destroy/recreate storm and transient default-sink
misreporting
Classification: Plasma
Product: plasmashell
Version First 6.7.1
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Audio Volume widget
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: 1.0
Summary:
Opening the system tray "Audio Volume" flyout (org.kde.plasma.volume applet)
triggers a burst of rapid ALSA/PipeWire node destroy-and-recreate cycles on one
of my audio output devices (a USB audio interface, MSI Onboard ALC4082 over
USB, VID:PID 0db0:e5c3). During the burst, `pactl get-default-sink` (and the
tray icon itself) rapidly alternates between the correct device and a
completely unrelated one (a second USB DAC, Hidizs S9Pro) for anywhere from ~10
to ~70 seconds, then self-resolves without intervention.
The System Settings "Sound" panel (kcm_pulseaudio), which ships in the same
plasma-pa package and uses the same PipeWire backend, does NOT reproduce this
when opened/used the same way. This strongly points at something specific to
the tray applet's activation path rather than the shared backend.
Evidence:
- pw-mon capture during a click-triggered episode shows PipeWire's `default`
metadata object (the actual persisted default-sink target) had ZERO change
events during a 66-second episode that showed 115 fresh node object creations
(new object.id each time) for the same ALSA sink. This means the flyout is
causing something to repeatedly destroy/recreate the device's PCM node, not the
configured default itself changing.
- plasmashell's own PipeWire client (application.name=plasmashell) owns zero
stream/node objects in the capture, so the trigger doesn't appear to go through
plasmashell's own client connection.
- The installed libplasma-volume-declarative.so (from this plasma-pa version)
statically links PulseAudioQt::VolumeMonitor and calls
pa_stream_set_monitor_stream, i.e. the peak-level monitoring feature described
in bug 449532 (which identified VolumeMonitor as a source of
PipeWire-interaction crashes in 2022) is present and active in current
plasma-pa.
- Bug 457023 ("Applet leaks audio sinks with Pipewire and WEBRTC")
independently reports "every time the applet is activated, a new audio sink is
created" - matching the destroy/recreate pattern seen here, in an earlier
plasma-pa version (5.25.3).
Environment notes:
The affected USB audio device has an independent, confirmed kernel-level
clock-source-validation quirk (snd_usb_audio, quirk_flags 0db0:e5c3:0x60) that
makes it comparatively fragile under repeated re-opens. It's possible the
applet-activation behavior described in 457023 is a long-standing,
mostly-harmless-on-typical-hardware quirk that becomes visibly disruptive
specifically on hardware whose ALSA renegotiation is already fragile - which
would explain why this hasn't been a widely-reported blocking issue.
Steps to reproduce:
1. Have a USB audio device selected as default sink (particularly one with
fragile clock-source handling, though this may reproduce more subtly on other
hardware too).
2. Click the system tray speaker icon to open the Audio Volume flyout.
3. Observe (via `pactl get-default-sink` polled at high frequency, or pw-mon)
rapid default-sink flapping and/or ALSA node destroy/recreate events for tens
of seconds.
4. Note that opening System Settings > Sound instead does not reproduce this.
Related bugs:
- Bug 457023 - Applet leaks audio sinks with Pipewire and WEBRTC
- Bug 449532 - Volume monitoring feature causes plasma-pa to crash
pipewire-pulse when using headset profile
--
You are receiving this mail because:
You are watching all bug changes.
