Created attachment 139290 [details] the bug in action SUMMARY When using Pipewire and there's audio playing all pinned but not running icons get the Mute Audio button STEPS TO REPRODUCE 1. make sure you're using pipewire in place of pulseaudio 2. play media 3. observe the task manager icons OBSERVED RESULT all pinned but not running icons get a "Mute" button EXPECTED RESULT only the apps playing audio should get the mute button SOFTWARE/OS VERSIONS KDE Plasma Version: 5.22 KDE Frameworks Version: 5.82 Qt Version: 5.15.2 ADDITIONAL INFORMATION confirmed this issue on 5.20 and 5.21 as well
Can you post the output of pacmd list-sink-inputs
(In reply to Kai Uwe Broulik from comment #1) > Can you post the output of pacmd list-sink-inputs pacmd doesn't exist, probably only a thing on pulseaudio proper and not pipewire-pulse
Update: seems to only happen when there are ALSA clients running
*** This bug has been marked as a duplicate of bug 417457 ***
(In reply to Reid from comment #3) > Update: seems to only happen when there are ALSA clients running I switch to PulseAudio output in Audacious and I can still reproduce the bug. The bug is gone after plasmashell --replace Operating System: openSUSE Tumbleweed 20210708 KDE Plasma Version: 5.22.80 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-1-default (64-bit) Graphics Platform: X11 Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD RENOIR
Can confirm in Fedora 34 with Elisa. While it's playing audio, the audio indicator appears on other pinned-but-not-running apps maybe 50% of the time.
(In reply to Reid from comment #3) > Update: seems to only happen when there are ALSA clients running After multiple login and logout, I can confirm when output is set to ALSA instead of pulseaudio, the bug can be always reproduced.
>> Can you post the output of pacmd list-sink-inputs This still needs doing
(In reply to David Edmundson from comment #8) > >> Can you post the output of pacmd list-sink-inputs > > This still needs doing When playing audio and the bug happens: No PulseAudio daemon running, or not running as session daemon.
On Arch Linux, I'm experiencing this bug with pipewire, pipewire-pulse, and pulseaudio-alsa installed. This means plasmashell is using the Pulse(?) API to talk to pipewire, and ALSA apps are using pulseaudio-alsa to speak Pulse to pipewire-pulse/pipewire (rather than speaking ALSA to pipewire). It appears that somewhere in the multiple layers of shims, the "app playing audio" information gets lost. I can't run pacmd easily, since that ships with the pulseaudio package, which conflicts with pipewire-pulse. * If I extract the pulseaudio package and run pacmd with pipewire-pulse running (but not pulseaudio), I get "No PulseAudio daemon running, or not running as session daemon." * If I remove pipewire-pulse and install pulseaudio (but leave pipewire installed), then Pipewire is effectively disabled and this bug no longer occurs. If I install pipewire-alsa and uninstall pulseaudio-alsa (with either pulseaudio or pipewire-pulse installed/running), now ALSA apps are using pipewire-alsa to talk directly(?) to pipewire. I no longer get volume keys in the task manager. `aplay /dev/urandom` works, Audacity works, but RtAudio apps (BambooTracker, exotracker) hang and burn CPU instead of playing audio properly. I can debug this if desired. Should I report a bug at RtAudio or PipeWire? Or debug first and then report a bug?
> If I install pipewire-alsa and uninstall pulseaudio-alsa (with either > pulseaudio or pipewire-pulse installed/running), now ALSA apps are using > pipewire-alsa to talk directly(?) to pipewire. I no longer get volume keys > in the task manager. Update: I'm using pipewire-alsa, and I'm again seeing speaker mute icons in the task manager when playing audio in Audacity (flatpak) in ALSA mode. Additionally, this bug isn't as simple as ALSA being broken. The Audacious music player triggers this bug (mute icon on pinned apps) in *PulseAudio* mode, but *not* in ALSA mode (mute icon on Audacious). mpv (not sure if Pulse or ALSA) triggers this bug, but Firefox (pulse-rust) does not. Restarting plasmashell (I'm using systemd Plasma startup, so `systemctl --user restart plasma-plasmashell`) while Audacious is playing in PulseAudio makes the mute icon appear correctly, and it continues to appear correctly after pausing/stopping and resuming playback. Switching to ALSA and back to Pulse, or restarting Audacious, makes the bug return. In other news, many apps are misbehaving when running under PipeWire. While Audacious is playing, changing system volume or beginning Audacity playback has an unusually long audio delay (slight delay in Audacious ALSA, longer delay in Audacious PulseAudio, both delays increase with longer Audacious buffer sizes, as if Audacious is causing PipeWire's latency to increase up to pipewire.conf's default.clock.max-quantum). Audacious (forgot if PulseAudio or ALSA) *sometimes* makes Audacity hang while starting up. Sublime Text is hanging for ~30 seconds in (pa_threaded_mainloop_wait -> pthread_cond_wait@@GLIBC_2.3.2) when trying to close a tab and play a ding. In the pipewire-alsa bug, the process is hanging on (snd_pcm_mmap_writei -> ... -> poll), but this only happens in BambooTracker after I load a different file and *then* try playback (before loading a file, playback works fine).
(In reply to qydwhotmail from comment #7) > (In reply to Reid from comment #3) > > Update: seems to only happen when there are ALSA clients running > > After multiple login and logout, I can confirm when output is set to ALSA > instead of pulseaudio, the bug can be always reproduced. Do you have pulseaudio-alsa installed? Try to remove it.
(In reply to qydwhotmail from comment #9) > (In reply to David Edmundson from comment #8) > > >> Can you post the output of pacmd list-sink-inputs > > > > This still needs doing > > When playing audio and the bug happens: > > No PulseAudio daemon running, or not running as session daemon. Use pactl, not pacmd. pactl list sink-inputs
I, too, just had this bug. Right now, after removing pulseaudio-alsa, making alsa clients to use pipewire-alsa only, it seems to work correctly. I'll reply here if see this behavior again.
I'm experiencing the bug even without the pulseaudio-alsa package installed.
(In reply to valdikss from comment #12) > (In reply to qydwhotmail from comment #7) > > (In reply to Reid from comment #3) > > > Update: seems to only happen when there are ALSA clients running > > > > After multiple login and logout, I can confirm when output is set to ALSA > > instead of pulseaudio, the bug can be always reproduced. > > Do you have pulseaudio-alsa installed? Try to remove it. (In reply to valdikss from comment #12) > (In reply to qydwhotmail from comment #7) > > (In reply to Reid from comment #3) > > > Update: seems to only happen when there are ALSA clients running > > > > After multiple login and logout, I can confirm when output is set to ALSA > > instead of pulseaudio, the bug can be always reproduced. > > Do you have pulseaudio-alsa installed? Try to remove it. I do not have pulseaudio-alsa in openSUSE. alsa-plugins-pulse and alsa-plugins-pulse-32bit are not installed.
*** Bug 441289 has been marked as a duplicate of this bug. ***
*** Bug 443632 has been marked as a duplicate of this bug. ***
*** Bug 443896 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/653
I think the above MR is not a correct fix for this bug. To summarize my findings in the above MR, the issue occurs when some sink inputs (audio playback streams) are assumed to come from PID 0 (which is the PID plasmashell associates with inactive apps). This happens because plasmashell and plasma-pa load the stream before loading the client (process) that created the stream, and when trying to find the PID of the client owning the stream (https://invent.kde.org/plasma/plasma-desktop/-/blob/master/applets/taskmanager/package/contents/ui/PulseAudio.qml#L79), plasmashell doesn't find a client and falls back to PID 0 (and caches it for the lifetime of the stream). Why does plasma-pa load the stream before the client, when pipewire-pulse informs plasma-pa about the client before the stream? Because plasma-pa has a race condition which can delay handling (client/stream/etc.) insertions past later removals (removals are handled instantly, while insertions are only handled after a round-trip to pipewire-pulse to request more information). An excerpt from https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/653#note_330292: message m_sinkInputs update 52 , defer sink_input_callback() message m_sinkInputs message remove 52 , eager removeEntry() message m_clients message remove 34 , eager removeEntry() message m_clients update 34 , defer client_cb() message m_sinkInputs update 52 , defer sink_input_callback() ... sink_input_callback() eol 0 info 0x7ffc66973fd0 index 52 client_cb() eol 0 info 0x7ffc66974120 index 34 sink_input_callback() eol 0 info 0x7ffc66973fd0 index 52 ... message m_sinkInputs update 52 , defer sink_input_callback() sink_input_callback() eol 0 info 0x7ffc66973fd0 index 52 sink added: 52 pipewire-pulse sent messages to remove the sink and client, then add the client and sink. m_sinkInputs.updateEntry(52) m_sinkInputs.removeEntry(52) m_clients.removeEntry(34) m_clients.updateEntry(34) m_sinkInputs.updateEntry(52) But plasma-pa delayed the first callback invoking `m_sinkInputs.updateEntry(52)` past the `removeEntry` calls: m_sinkInputs.removeEntry(52) m_clients.removeEntry(34) m_sinkInputs.updateEntry(52) m_clients.updateEntry(34) m_sinkInputs.updateEntry(52) This caused the sink to be incorrectly recreated with stale data *after* it had been removed. The `m_pendingRemovals` mechanism didn't kick in to prevent the reordering (but in other cases it can *create* issues, and fail to register a client even when it's seen in pactl). And then plasmashell saw sink 52, tried to find the associated client/PID, but Client 34 was (correctly) not registered in plasma-pa, so plasmashell assumes it belongs to PID 0 instead.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-pa/-/merge_requests/90
*** Bug 446732 has been marked as a duplicate of this bug. ***
*** Bug 447093 has been marked as a duplicate of this bug. ***
PipeWire upstream is making changes to avoid reusing PulseAudio IDs. We discovered some race conditions between WirePlumber and PipeWire, so wtay made PipeWire IDs unique in https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/bae0d16e09ef0540c78170496eb18d01ee43f645, then reverted it in https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/b1fb4a266022831abdf447975f17218709e38bf7, and now they're decoupling reused PipeWire IDs from unique PulseAudio IDs in https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1d03923a974aa18d2d1eaaf5d1d2f5fa19dc669f. In my testing, the IDs reported by `pactl subscribe` are unique, so this issue *should* no longer happen in pipewire-git. Nonetheless I think this MR should be merged, since it's a cleanup of some deeply janky existing code I don't trust to be reliable. I'm not sure how it interacts with https://invent.kde.org/plasma/plasma-pa/-/merge_requests/95 though (both MRs are stalled lol).
After building pipewire from git, I can confirm that this issue is fixed in pipewire. Closing the bug now, we can still pursue the MR as a refactor.
Oh that's awesome!
*** Bug 451521 has been marked as a duplicate of this bug. ***