https://bugs.kde.org/show_bug.cgi?id=511276
--- Comment #10 from pallaswept <[email protected]> --- I know that's an RFC but I thought I should comment here first so I don't mess things up over there. Please let me know if I should add these comments to the actual RFC. > unmute all microphones (even those that were previously explicitely muted in > the applet). Please don't do that. If I muted the mic explicitly I explicitly want it muted. I probably should also mention that not all source devices are mics https://bugs.kde.org/show_bug.cgi?id=435142#c8 https://bugs.kde.org/show_bug.cgi?id=508170 Thinking about something positive to add to this, I'm trying to imagine a 'right' way to do it and... I'm not so sure that the concept of a global mute is practically possible. We don't have a way to identify actual mics (as distinct from other sources) or actual speakers (distinct from other sinks). In the above bug, we settled on avoiding virtual devices, but that's already unreliable, and is not going to work in future wireplumber either, as physical devices are being 'wrapped' in loopbacks that are virtual (that's in wireplumber git right now); also it won't work for role-based policy in wireplumber, for example my notifications sounds currently are routed through a virtual device which is not marked as virtual, so that notification volume control is possible through the UI. I understand that's not common on desktops (IMO it should be though! We still have a non-functional volume control for notifications in pavucontrol and friends, leftover from the pulseaudio days, and currently not implemented in pipewire, even though it could be) but it's normal for cars, for example (I'm thinking of some news I saw recently about Mercedes running plasma - PS, that's one classy vehicle) I'm presently trying to prepare for my future where my hands will be useless due to illness and I'll need to control everything by voice. I'm not there yet but I know a lot of people are. It'll be a real problem if muting my mic to applications also mutes the mic I'm using to control the machine... That makes me think about the effect of globally muting speakers, for blind users. But, I do understand the benefits of having a 'panic button' where we will *definitely* not be capturing/playing back *any* audio. I don't want to make sure it's so flexible that a person might hit 'mute' and their MS Teams meeting still hears them burp and there's a future bug report here about "I muted and it didn't work you got me fired". So there's Mute/Unmute the current default device (currently broken per linked bug reports) Mute everything that isnt muted/unmute everything that wasnt muted (the existing behaviour that caused the confusion that led to this bug report) Mute/Unmute everything (regardless of existing mute settings) (kinda dangerous honestly) And none of them work perfectly all of the time and none of them play nicely together. And then, there's keybinds vs GUI elements (which is the actual problem being reported in this bug) vs other means of muting (eg wpctl) Ugh, it's a rabbit hole :( Sorry team, not trying to be difficult here, but just some food for thought. At this point, with all of the above considered, I'd say that the only mute that can work reliably without quite severe consequences, is mute/unmute of the default sink/source. Perhaps a global 'mute/unmute everything regardless' / 'panic button' might be in order, but obviously that shouldn't be the thing done by the GUI elements or default keybinds, as it's destructive by nature. In an effort to bring some solution with these problems and keep things positive: The only way that I can imagine a global mute working, is if the user can select the devices that would be included/excluded in that process. Plasma already has mechanisms in place to modify pipewire params per-device (the renaming) and that or a similar mechanism could easily set metadata for the devices, which plasma could then use to make informed decisions about whether to effect the device or not, in the case of a global mute. -- You are receiving this mail because: You are watching all bug changes.
