https://bugs.kde.org/show_bug.cgi?id=508170
Bug ID: 508170
Summary: Mic/Speaker mute has unintended effect
Classification: Plasma
Product: plasmashell
Version First master
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Audio in general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: 1.0
Created attachment 183999
--> https://bugs.kde.org/attachment.cgi?id=183999&action=edit
qpwgraph screenshot showing virtual sinks/sources in action
This is a continuation of https://bugs.kde.org/show_bug.cgi?id=435142 . I'll
try to be informative but for the quick version, see the attached image for an
illustration of why muting all sinks/all sources can effectively mute a lot
more than intended.
A recent change to the microphone mute widget and keyboard shortcut, is that
they will now mute not only the default device, but all source nodes.
This is a problem as source nodes serve functions other than just microphones
or similar input devices.
The same problem already exists for the speaker mute widget, which will mute
all sinks, which likewise includes nodes that are not limited to actual output
devices (speakers, headphones, etc)
For an example, the application 'easyeffects' uses both a virtual sink and
source, in order to route audio through it for effects. This is very popular
for use as either virtual surround for headphones, EQ for headphones and
speakers/rooms, or for noise cancelling for mics.
A more complex example is shown in an annotated screenshot from qpwgraph in the
attachment. This shows several use-cases in one; noise cancelling mics,
routing/separating audio, virtual surround, EQ, speaker treatment; as you can
imagine there is a large userbase which uses at least one of these. All of them
together is pretty much a 'normal' setup for a pro-audio or game streaming
use-case.
In the screenshot, the audio is shown with pink arrows, flowing in from the
hardware devices in green boxes to the left and out to the hardware devices in
green on the right. Between the hardware, would be applications (shown crossed
out in pink) which record or play back audio (which may themselves consist of
virtual sinks/sources, like easyeffects). Either side of those, between the
apps and the hardware, there are layers of virtual sinks (in blue boxes) and
virtual sources (in red boxes) which provide audio processing and routing for
the session.
Now, I may have put in one or two extra boxes (sorry it took me ages I don't
wanna redo it lol) but the punchline is the same: between the hardware, and
surrounding the apps on both sides, there are virtual devices, which will be
muted by these widgets/keybinds, and depending on the design of the system, if
it mutes all source *or* sink nodes, one of these buttons could effectively
mute all input *and* output.
For a couple of real-world examples: If I try to mute my speakers while
recording in OBS, it mutes all the OBS inputs, because all my apps go to
separate virtual devices so that they can be recorded on separate audio tracks
in OBS. If I am screensharing an application with audio, and I mute my
speakers, the other end of the call can no longer hear the application, because
the speaker mute also mutes the virtual sink that I am playing the application
in to. If the microphone mute does this to all sources, then it will mute that
screenshare, too, so now I can't mute my mic during calls.
I'm unsure of the best way to deal with this. I would have guessed that only
muting the default device would have been it, and I clearly would have been
wrong! :D Perhaps it could be an option to have that behaviour, or perhaps an
option - or just hardcode it - to avoid virtual nodes with the mute
widgets/keybinds?
Avoiding virtual nodes will work out of the box for almost everyone, and has
the added benefit of allowing users to write pipewire rules to specify nodes
they do/do not want muted by the widgets/keybinds, is consistent with other KDE
audio stuff, and probably simplest to code, so that's my favourite so far - at
least in terms of something to mitigate this in the short term.
If there's anything I could do to help with this please do ping me.
--
You are receiving this mail because:
You are watching all bug changes.
