https://bugs.kde.org/show_bug.cgi?id=438565
nyanpasu64 <nyanpas...@tuta.io> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |CONFIRMED
--- Comment #21 from nyanpasu64 <nyanpas...@tuta.io> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
