Created attachment 183999 [details] 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.
Simplest thing is probably to exclude virtual sinks and sources from global mute behaviors. Would there be any reason not to do this, I wonder?
(In reply to Nate Graham from comment #1) > Would there be any reason not to do this, I wonder? It seems pretty safe to me, but I welcome any input. I've been chewing on this one a lot because you know how it is, there's always that one unexpected use-case ... The hypothetical concern is that a user wants to press mute and mute a virtual device. I can think of several use-cases where a person might be using a virtual device as an input (mic) in their app, but in nearly every example that comes to mind, there's a real mic at the end of it all, which would be muted by the widget, so the result would be the intended one (mute my mics). I imagined that if a person were playing background noise or karaoke backing, and mixing it with their mic through a virtual node, if they pressed mute, the mic would mute as expected, and the background noise/karaoke backing would keep going. That one feels like I'm really stretching my imagination honestly. One potential issue I thought of is where the root source of the audio is not a real device, but an application. Like say a person uses some kind of voice synthesis like TTS (eg for a11y or vtubers). Since that's an application, it wouldn't be muted by the mic widget anyway, but if they were using a virtual device to route that app as a 'microphone' into other apps, and consequently provide them a source node; that is currently muted if it is the default device, but wouldn't be muted in this concept because it's virtual. However, they could avoid this, by marking that virtual device as real (ie node.virtual=false) and I doubt that would be a challenge for anyone who had already configured it to that point (they would just be adding this one property to the several they had already set). (and they'll also get volume controls for it in the widget/pavucontrol/etc so that's preferable anyway) (and they probably need to do it anyway so apps will even see it, so chances are they already have) That last one is honestly the only vaguely legit issue that I could imagine. It doesn't seem severe thanks to the easy fix/prevention probably already should be in place, but I mention it anyway just to be thorough. I'll keep mulling it over and see if I can think of anything else but that's all for now.
That's preeeeeetty esoteric. I'd say we can start by just muting the physical devices and see if that's good enough.
(In reply to Nate Graham from comment #3) > That's preeeeeetty esoteric. I'd say we can start by just muting the > physical devices and see if that's good enough. Not good enough for me, at least. I stream on Twitch, and my mute button has become useless for me now, as it also mutes my game audio. Honestly I liked the old behavior, where it just muted the default device. I'm surprised this wasn't turned into an option. Changing the default behavior for anything that might've been widely used without a way to "go back" is a bit of a head-scratcher.
(In reply to John Mickelonis from comment #4) > (In reply to Nate Graham from comment #3) > > That's preeeeeetty esoteric. I'd say we can start by just muting the > > physical devices and see if that's good enough. > > Not good enough for me, at least. > > I stream on Twitch, and my mute button has become useless for me now, as it > also mutes my game audio. Without knowing how your setup is wired, there's a strong likelihood that the game audio should be passing through virtual devices, so that solution would be OK for you. If you're playing on the same PC you're streaming from. If you had the audio coming in via a hardware cable from another PC to a line-in on your linux streaming PC (dual-PC streaming normal kind of setup) this won't help, though. You could mark that device as virtual, and exclude it from the Mic mute, but yeh, assuming all audio inputs are microphones is incorrect... and there's no real way to programmatically tell them apart. I mean, think of a hardware mic preamp that outputs into a line-level input on the machine; it's a mic, physically, but as far as the system is concerned, it's just a normal line-in. You might consider streaming the audio digitally from the game PC to the stream PC in that case. It's better anyway, and it'd all be virtual devices. Still... making the "mic mute" key perform "force mute all input devices" is a problem, as with making the "speaker mute" key perform "force mute all output devices". > Honestly I liked the old behavior, where it just muted the default device. The new behaviour copies the old behaviour for sinks, which is "let's make it uniform in behaviour" which makes sense... except the old behaviour for sinks was also a problem (which nobody at KDE knew about until I brought it up here, so this isn't really their fault)... so now it's uniformly a problem. That'll be all fine when the solution is uniformly applied :) But yeh this is kinda old for such a serious bug report. I know it doesn't effect everyone but it does effect several extremely common use-cases and the effect is catastrophic. Is there anything we could do to help, Nate?
A workaround: - Open KDE System Settings - Go to Keyboard... Shortcuts (or just start typing "shortcuts" to get there the easy way) - Click 'Add New' in the top right corner, and select 'Command or Script' - In the command type: - For mic mute: wpctl set-mute @DEFAULT_AUDIO_SOURCE@ toggle _ For speaker mute: wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle - In 'Name' give it something useful for you. Click 'Add' - In System Settings there is a column on the right Labelled 'Custom shortcuts' and a button immediately below the title labelled 'Add'. Click that. - Now press your mute key or whatever you want to bind to mute the thing. - You may be prompted that the key is already assigned to the normal action, Click Reassign. Enjoy. It's not as nice as a real fix because it doesn't work in the GUI input elements, but it'll get your ability to stream and voice call and stuff.
(In reply to pallaswept from comment #5) > Without knowing how your setup is wired, there's a strong likelihood that > the game audio should be passing through virtual devices, so that solution > would be OK for you. If you're playing on the same PC you're streaming from. It actually does pass through virtual devices, > > If you had the audio coming in via a hardware cable from another PC to a > line-in on your linux streaming PC (dual-PC streaming normal kind of setup) > this won't help, though. You could mark that device as virtual, and exclude > it from the Mic mute, but yeh, assuming all audio inputs are microphones is > incorrect... and there's no real way to programmatically tell them apart. I > mean, think of a hardware mic preamp that outputs into a line-level input on > the machine; it's a mic, physically, but as far as the system is concerned, > it's just a normal line-in. > > You might consider streaming the audio digitally from the game PC to the > stream PC in that case. It's better anyway, and it'd all be virtual devices. > > Still... making the "mic mute" key perform "force mute all input devices" is > a problem, as with making the "speaker mute" key perform "force mute all > output devices". > > > Honestly I liked the old behavior, where it just muted the default device. > > The new behaviour copies the old behaviour for sinks, which is "let's make > it uniform in behaviour" which makes sense... except the old behaviour for > sinks was also a problem (which nobody at KDE knew about until I brought it > up here, so this isn't really their fault)... so now it's uniformly a > problem. > > That'll be all fine when the solution is uniformly applied :) > > But yeh this is kinda old for such a serious bug report. I know it doesn't > effect everyone but it does effect several extremely common use-cases and > the effect is catastrophic. Is there anything we could do to help, Nate? (In reply to pallaswept from comment #6) > A workaround: > > - Open KDE System Settings > - Go to Keyboard... Shortcuts (or just start typing "shortcuts" to get > there the easy way) > - Click 'Add New' in the top right corner, and select 'Command or Script' > - In the command type: > - For mic mute: > wpctl set-mute @DEFAULT_AUDIO_SOURCE@ toggle > _ For speaker mute: > wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle > - In 'Name' give it something useful for you. Click 'Add' > - In System Settings there is a column on the right Labelled 'Custom > shortcuts' and a button immediately below the title labelled 'Add'. Click > that. > - Now press your mute key or whatever you want to bind to mute the thing. > - You may be prompted that the key is already assigned to the normal > action, Click Reassign. > > Enjoy. It's not as nice as a real fix because it doesn't work in the GUI > input elements, but it'll get your ability to stream and voice call and > stuff. This is perfect, thank you!
Oof, sorry for the huge distracting reply. I thought I edited out most of that, and I guess we can't go back and fix our comments.