SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Set `default.clock.allowed-rates = [ 48000 44100 96000 ]` as described in https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#setting-sample-rates and restart pipewire 2. No plasma PA clients available in `pw-top` (because the widget was never opened after the pipewire restart): Try playing audio and pause it: after some time bluetooth headset stops playing white noise which means that it has entered power-saving state Trying sample rate switch: Play some audio with 44100 sample rate: (`pw-top`) R 68 1024 44100 20.1us 27.4us 0.00 0.00 0 S16LE 2 48000 bluez_output.00_0A_45_0E_94_F7.1 R 61 1102 44100 --- 0.0us --- 0.00 0 F32LE 2 44100 + alsa_playback.mpv The graph is running at 44100 Pause the audio and switch to the 48000 audio source: The graph switches to 48000 sample rate R 68 2048 48000 33.1us 7.9us 0.00 0.00 0 S16LE 2 48000 bluez_output.00_0A_45_0E_94_F7.1 I 61 1102 44100 --- 0.0us --- 0.00 0 F32LE 2 44100 + alsa_playback.mpv R 74 3600 48000 13.6us 13.1us 0.00 0.00 0 F32LE 2 48000 + Firefox 3. Open the plasma-pa widget. Observe that a new client appeared for the output device: R 68 1024 44100 102.3us 49.2us 0.00 0.00 0 S16LE 2 48000 bluez_output.00_0A_45_0E_94_F7.1 I 61 1102 44100 --- 0.0us --- 0.00 0 F32LE 2 44100 + alsa_playback.mpv I 74 3600 48000 20.7us 18.9us 0.00 0.00 0 F32LE 2 48000 + Firefox R 82 1 25 50.2us 9.8us 0.00 0.00 0 F32LE 1 25 + Plasma PA pw-top shows the `Plasma PA` client to be in `R=RUNNING` state The bluetooth headset is now playing white noise without stopping (power management no longer works) Play some audio with 44100 sample rate: (`pw-top`) R 68 1024 44100 37.0us 28.0us 0.00 0.00 0 S16LE 2 48000 bluez_output.00_0A_45_0E_94_F7.1 R 61 1102 44100 --- 0.0us --- 0.00 0 F32LE 2 44100 + alsa_playback.mpv I 74 3600 48000 20.7us 18.9us 0.00 0.00 0 F32LE 2 48000 + Firefox R 82 1 25 20.9us 6.3us 0.00 0.00 0 F32LE 1 25 + Plasma PA R 83 1 25 1.0ms 3.1us 0.04 0.00 0 F32LE 1 25 + Plasma PA The graph is running at 44100 Pause the audio and switch to the 48000 audio source: R 68 1024 44100 60.7us 42.0us 0.00 0.00 0 S16LE 2 48000 bluez_output.00_0A_45_0E_94_F7.1 I 61 1102 44100 --- 0.0us --- 0.00 0 F32LE 2 44100 + alsa_playback.mpv R 82 1 25 13.1us 7.8us 0.00 0.00 0 F32LE 1 25 + Plasma PA I 83 1 25 459.4us 3.7us 0.02 0.00 0 F32LE 1 25 + Plasma PA R 84 3600 48000 22.2us 28.9us 0.00 0.00 0 F32LE 2 48000 + Firefox The graph no longer switches to 48000 sample rate. The graph is stuck at the last used sample rate OBSERVED RESULT `Plasma PA` client always stays in `R=RUNNING` state which prevents the graph from switching sample rate and prevents bluetooth devices to entering the suspend state EXPECTED RESULT `Plasma PA` client should be able to switch to `I=IDLE` state SOFTWARE/OS VERSIONS $ kinfo Operating System: Arch Linux KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 Kernel Version: 6.6.2-zen1-1-zen (64-bit) Graphics Platform: offscreen Processors: 16 × AMD Ryzen 7 5800H with Radeon Graphics Memory: 23.1 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3050 Ti Laptop GPU/PCIe/SSE2 ADDITIONAL INFORMATION pipewire 0.3.85 wireplumber 0.4.16
After restarting `plasmashell` the `Plasma PA` client disappears from `pw-top` which fixes low power state for bluetooth devices and pipewire sample rate switch
On the pipewire graph there is a virtual `plasma pa` node which gets created and automatically connected to every `monitoring` port when plasma-pa widget is first opened
Seems like the are couple of lifetime bugs. First, depending on whether the applet is in system tray or not, it may fail to clean up its nodes when full representation is closed: Applet in system tray behaves better than a standalone on a panel. Second, the system tray applet may fail to clean up nodes of a paused playback stream. I have an mpv playing some music, and each time I open Audio applet in system tray, I see a new "Plasma PA" node being created in pw-top. They keep stacking up until I close mpv or restart Plasma. Interestingly, standalone applet does not exhibit such an issue.
I filed an upstream bugreport to speech-dispatcher because their streams are getting stuck in limbo PA_STREAM_CREATING state causing leaks in my case. I assume there might be more apps out there that create buggy streams, which we can not immediately disconnect (because the rules) and which can not be disconnected later via state change callback (because state never changes). https://github.com/brailcom/speechd/issues/871
Found another closely related upstream bug report in pipewire: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2168
So is it purely an upstream bug? Or do we think there's anything we can do here?
(In reply to Nate Graham from comment #6) > So is it purely an upstream bug? Or do we think there's anything we can do > here? I think we can delete and then recreate plasma-pa node as a workaround