https://bugs.kde.org/show_bug.cgi?id=375943
--- Comment #44 from pallaswept <pallasw...@proton.me> --- > I wonder if we should consider just removing the audio badge functionality > entirely. If it simply can't be made to work accurately, it's something > people can't rely on and therefore not something we should be implicitly > promising by making available. I mean you're not wrong it is kinda busted but... It works for most apps, and even on those where it's inaccurate, I still find it useful. We get a quick, per-application ID and mute button either way. It would be nice if we also got it per-window, but I still think it's worth keeping without that. I understand the replies above see the entire feature as useless, but obviously their use-case is 'identify which window from this one app is playing the sound' where it is still useful for 'identify which application is playing the sound'. > If the issue is essentially impossible to fix with the relevant software > stack's current technical infrastructure, I spent a lot of hours testing different apps' behaviours but it made for a very long reply, so if you want those details feel free to quiz me. It seems like this is mostly a firefox and chrome thing, and is fixable on firefox. Chrome looks hopeless, there's very little metadata to work with. Media streams are all just called "playback". But if they did set some identifiable metadata, it could work. I guess the 'correct' thing is to use the APIs of the sound servers. Kai mentioned in the first comment there pulse's window.id and now pipewire has application.id natively and supports the pulse stuff as well. https://freedesktop.org/software/pulseaudio/doxygen/proplist_8h.html#a9fdf6146c8c9f1a5bf2bae0f5ac15c80 https://docs.pipewire.org/group__pw__keys.html#ga7e7975fdc1d4879492d18bd5737fc7d7 If task manager used that method, it'd at least be reasonable to say "well we support it, now it's up to your app, closed downstream". That seems to go really well with my case manager hat ;) I noticed in the past few hours testing, examples of applications which already set this property, are kded, kdeconnectd and libcanberra It seems very rare, though, and even those which set it don't appear to be window-specific. It may be technically correct and theoretically perfect, but given lack of application support, it's probably the least-functional approach in reality. So even if Task Manager did this, it would be nice to have a fallback to the per-application behaviour we have now, or maybe an enhanced version which matches other more specific stream metadata beyond application name/pid/binary name/etc, like grabbing media.name to specify firefox tabs. Trying to think of alternatives to those approaches, if keeping the promise is the goal, perhaps a graphical approach to an audio problem... sound icons which play from a different PID to the window shown, could be marked somehow. Y'know like something that communicates, 'this sound icon is different to the others, that sound could be from any of these windows, so if you click it, we mute them all'. Something like a chain-link badge on the icons, to indicate they are 'linked'? So yeh TLDR it is kinda broken, and kinda fixable but also kinda only in theory... but it's still good. Pls no delete mute icon. -- You are receiving this mail because: You are watching all bug changes.
