Bug description
On Asahi Fedora (GNOME), the orange microphone privacy indicator in the
menu bar stays permanently lit, even when no app is recording.
This is noted as a known bug in the Asahi docs
(https://asahilinux.org/docs/sw/audio-userspace/) but there is no
issue to track it or collect workarounds, so I am opening one.
Probable root cause (may be wrong — happy to be corrected)
My best guess is that WirePlumber creates a PipeWire filter-chain to
process raw Apple Silicon microphone audio (beamforming, EQ, gain), and
that this node ends up visible through PipeWire's PulseAudio
compatibility layer as a permanent source-output:
pactl list source-outputs short
# → 83 4294967295 78 PipeWire float32le 3ch 48000Hz
GNOME Shell's _maybeShowInput lights the indicator for any
source-output whose application.id is not in a hard-coded skip list.
The node in question has no application.id and a stream name of
"WirePlumber", so it is never skipped → indicator always on.
The stream appears corked/inactive when nothing is recording:
pactl list source-outputs | grep Corked
# → Corked: yes
I have not verified this at the PipeWire/WirePlumber level — if the
actual cause is different I would appreciate a pointer.
Affected systems
All Apple Silicon Macs running Fedora Asahi Remix with microphone
support enabled. Confirmed on my machine; model identifiers likely
include j293, j313, j314, j316, j413, j414, j415, j416, j493 and
others.
Possible upstream fixes
- WirePlumber: stop registering the filter-chain input node as a visible
PulseAudio source-output, or annotate it so GNOME/Plasma can skip it
- GNOME Shell: skip corked/non-running source-outputs (note: the
PipeWire PA compat layer appears to return state INVALID for all
source-outputs via GVC, so corked-state detection via get_state()
is unreliable — see workaround comment for details)
A local GNOME Shell extension workaround is working for me — see the
comment below.
Bug description
On Asahi Fedora (GNOME), the orange microphone privacy indicator in the
menu bar stays permanently lit, even when no app is recording.
This is noted as a known bug in the Asahi docs
(https://asahilinux.org/docs/sw/audio-userspace/) but there is no
issue to track it or collect workarounds, so I am opening one.
Probable root cause (may be wrong — happy to be corrected)
My best guess is that WirePlumber creates a PipeWire filter-chain to
process raw Apple Silicon microphone audio (beamforming, EQ, gain), and
that this node ends up visible through PipeWire's PulseAudio
compatibility layer as a permanent source-output:
GNOME Shell's
_maybeShowInputlights the indicator for anysource-output whose
application.idis not in a hard-coded skip list.The node in question has no
application.idand a stream name of"WirePlumber", so it is never skipped → indicator always on.The stream appears corked/inactive when nothing is recording:
I have not verified this at the PipeWire/WirePlumber level — if the
actual cause is different I would appreciate a pointer.
Affected systems
All Apple Silicon Macs running Fedora Asahi Remix with microphone
support enabled. Confirmed on my machine; model identifiers likely
include j293, j313, j314, j316, j413, j414, j415, j416, j493 and
others.
Possible upstream fixes
PulseAudio source-output, or annotate it so GNOME/Plasma can skip it
PipeWire PA compat layer appears to return state
INVALIDfor allsource-outputs via GVC, so corked-state detection via
get_state()is unreliable — see workaround comment for details)
A local GNOME Shell extension workaround is working for me — see the
comment below.