One of my Chrome windows is playing music - it's in a popup. The other chrome windows also appear to playing music in the task manager - I'm guessing it doesn't see any difference between the windows if they are from the same process.
Yes, there's unfortunately no way to tell. All sound playback "belong" to the main Chrome process. PulseAudio in theory supports applications adding a Window ID to the audio stream but in practise I've never seen anybody actually use this.
*** Bug 379021 has been marked as a duplicate of this bug. ***
This used to work a while back (some time after Fedora 25 was released). After some update it started to display this kind of behavior. I'm using firefox, before the regression only the window with the sound playing was marked. ATM all of the firefox windows are "marked" so in essence this feature became useless.
So is there anything we can do here? If not, we should unfortunately mark it as RESOLVED UPSTREAM; no sense in keeping an unfixable bug open forever. :/
*** Bug 377763 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #4) > So is there anything we can do here? If not, we should unfortunately mark it > as RESOLVED UPSTREAM; no sense in keeping an unfixable bug open forever. :/ It is, obviously, fixable since it used to work as intended. No one has bothered to find the source of the issue.
Everything is theoretically fixable. :) The question is, can we feasibly fix this, or is the root cause in Chrome or PulseAudio?
(In reply to Nate Graham from comment #7) > Everything is theoretically fixable. :) The question is, can we feasibly fix > this, or is the root cause in Chrome or PulseAudio? It exhibits the same behaviour with Chrome and Firefox so that can be eliminated.
Actually perhaps not. As Kai said: "All sound playback "belongs" to the main Chrome process. PulseAudio in theory supports applications adding a Window ID to the audio stream but in practise I've never seen anybody actually use this." If Firefox does the same thing, then they would both just be broken in the same way.
(In reply to Nate Graham from comment #9) > Actually perhaps not. As Kai said: > > "All sound playback "belongs" to the main Chrome process. PulseAudio in > theory supports applications adding a Window ID to the audio stream but in > practise I've never seen anybody actually use this." > > If Firefox does the same thing, then they would both just be broken in the > same way. I remember that this issue started to show up after a kde update. It's unlikely that both firefox and chrome were updated at the same time. I will try and dig up some older fedora kde live image and test it there with the latest firefox.
Created attachment 114820 [details] Kmix apps tab
Comment on attachment 114820 [details] Kmix apps tab Any knews about this issue? It is still present in KDE 5.12.6. I don't know if Dragan could test that past version of fedora to check if the behavior was correct. Anyways, I know that this is not the place to ask about this (maybe some admin could move to the apropiate product, kmix I suppose...), but it is in some way related to this issue. In the kmix applet, in the apps tab, all the streams of the same app (diferent tabs in firefox/chrome for example) has the same name. Is it posible to get the name of the tab of the browser and replace with this string in each stream? Sorry for the non-related question
BTW, that's not KMix, that's Plasma-pa.
(In reply to Nate Graham from comment #13) > BTW, that's not KMix, that's Plasma-pa. Thanks, I wrote a comment on a related bug. Sorry again for the inconvenience.
Dragan: What are the results of your test?
*** Bug 398475 has been marked as a duplicate of this bug. ***
Audio and Videoplayers send such informations for sure, since there are already plasma widgets, who display that text correctly. https://pictshare.net/g30voo1s2o.png
Still happens on current release. Tested with Firefox, Falkon, Chromium - all have audio icons on every window.
Let me add a sub-issue. Suppose, I have 2 Chrome windows open, one playing a video from YouTube and the other is not playing any video or audio, just displaying a webpage. In the task manager, both the instances shows the same thumbnails on hovering over them.
Created attachment 130932 [details] Both Chrome instances showing the same thumbnails while they should show different thumbnails
This is fixed in Plasma 5.22! See the fix for Bug 417457 which fixed this too.
Can reproduce with Firefox and Opera browser on neon unstable. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.26.80 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Graphics Platform: Wayland
Can you attach a screenshot of it?
Created attachment 152378 [details] screenshot Focused Firefox window has the sound icon despite it is not playing anything.
I can reproduce that with a classic Task manager or an Icons-Only Task Manager with grouping turned off.
I think it's not possible to fully fix it currently due to mpris depending on PID
Darn. :/
> All sound playback "belong" to the main Chrome process. PulseAudio in theory supports applications adding a Window ID to the audio stream but in practise I've never seen anybody actually use this. Does anyone know whether there's a bug in Firefox for tagging the window ID on Linux systems? I can try to file one if there's not an existing report. Do we know whether KDE would should the audio icon for the correct window if Firefox *did* tag the window correctly? In other words - do we support this feature?
*** Bug 467125 has been marked as a duplicate of this bug. ***
*** Bug 489243 has been marked as a duplicate of this bug. ***
I would recommend reading through all the related issue tickets because, at least to me, the conclusions reached in this ticket are wrong. My ticket #489243 (Muting one application mutes them all) has been marked as a duplicate of this issue .While I agree they might be related, the comments in this issue seem to revolve around tabs belonging to the same application (chrome or firefox are mentioned) whereas in my experience the issue cuts across multiple applications. The incorrect state icon and mute behaviour affects all applications currently playing audio at the time e.g. Muting a Steam game also mutes Elisa, Vivaldi (Chrome), VLC et al. Furthermore in my testing this is NOT a pulseaudio issue, since I can independently mute applications and different windows for the same application just fine through pavucontrol. The issues are specific to the taskbar and are a regression as others have noted. The only thing I haven't checked yet is whether this is connected in some way to a change from X11 to Wayland in the Fedora 40 release. This might be particularly relevant since I note this original ticket dates back 7 years and references Plasma 5, whereas for me the issue only started with an upgrade from Fedora 39 (Plasma 5 + X11) to Fedora 40 (Plasma 6 + Wayland).
Indeed, Bug 489243 and Bug 467125 look like different issues. I'll get this cleaned up.
Looks like this is working as expected for me with Firefox 134 (only one window in the Task Manager gets volume controls and a mute icon) which means it's a Chromium issue. Whatever Firefox does, Chromium needs to implement the same thing.
(In reply to Nate Graham from comment #33) > Looks like this is working as expected for me with Firefox 134 (only one > window in the Task Manager gets volume controls and a mute icon) which means > it's a Chromium issue. Whatever Firefox does, Chromium needs to implement > the same thing. I'm running the same Firefox version and it is still exhibiting the same behaviour (all firefox windows in the task manager have the sound playing icon). What distribution are you running?
Fedora KDE 41.
Also, MPRIS is coming from plasma browser integration for me, rather than Firefox's own built-in MPRIS media controls system. Either way, it shows that this is possible for the app (or rather, some code in the app) to do properly.
(In reply to Nate Graham from comment #36) > Also, MPRIS is coming from plasma browser integration for me, rather than > Firefox's own built-in MPRIS media controls system. Either way, it shows > that this is possible for the app (or rather, some code in the app) to do > properly. That is really strange, I'm also running Fedora 41 (fresh install) and I also have plasma integration Firefox plugin.
(In reply to Dragan from comment #34) > (In reply to Nate Graham from comment #33) > > Looks like this is working as expected for me with Firefox 134 (only one > > window in the Task Manager gets volume controls and a mute icon) which means > > it's a Chromium issue. Whatever Firefox does, Chromium needs to implement > > the same thing. > > I'm running the same Firefox version and it is still exhibiting the same > behaviour (all firefox windows in the task manager have the sound playing > icon). What distribution are you running? Still seeing the issue as well, with firefox-134.0.1 on Arch Linux (Plasma 6.2.5). Tested just now using a fresh user profile and default panels (no custom plasmoids, settings, etc) on X11 and Wayland. If this is application-side/downstream after all, a case should probably be opened on Firefox and Chromium's trackers if there's not one already.
I can also reproduce with Firefox 134 and its Plasma integration plugin. Operating System: Arch Linux KDE Plasma Version: 6.2.90 KDE Frameworks Version: 6.10.0 Qt Version: 6.9.0 Graphics Platform: Wayland
Ok, I figured out what's going on: my two Firefox windows came from different sessions, which resulted in them having different PIDs. If I open more non-new-session windows, they exhibit the problem here. It may still be unresolvable with the current state of PulseAudio and PipeWire, but I'll re-open this for now pending further investigation.
The core problem would seem to be that it is not windows that play sound but processes. A process can have one or more windows, and a process can have sound, but there's nothing inherently linking the sound, at the system level, to a particular window. As far as I know. But personally, I still see this as a bug, _someone's_ bug. :-P Off the top of my head, it would seem that some sort of extension is needed to permit a process to inform the window manager that a particular window is associated with sound output. And I believe that would mean different extensions for X11 and for Wayland. I could be wrong, though, I don't presently live in those worlds. :-)
As has been mentioned above, since browsers changed to a single process handling all audio, there's no way for KDE (or anything else) to do this, unless the client somehow identifies which audio stream belongs to which window. In pipewire, the media.name property of the client node contains the tab title, so we can know which audio stream belongs to which tab. So, what we need here is a way to know which tabs are in which window. I wonder, could the Plasma Integration browser plugin be enhanced to serve that purpose? This seems likely, since it already provides a list of tabs for krunner.
If the issue is essentially impossible to fix with the relevant software stack's current technical infrastructure, 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 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.
When the windows *are* grouped, in Firefox, the playing audio icon only shows on the thumbnail of the one playing the video *if* it's open to the same tab. It's just when the windows are ungrouped that the check fails. But surely we can extend the logic which lets us have the audio control only on the correct thumbnail to make it only appear on the correct ungrouped icon as well. Also the idea to take supplementary info from p-b-i to make it work even if it's *not* open to the same tab is a promising one. I really don't think we should remove the feature.
If we can make it work much better, I'm happy with keeping it. What I'm less happy about is a feature that's on by default but known to be broken with common use cases. This is a bug report generator, source of frustration for users, and black eye for us in YouTube reviews.
If what Bharadwaj says is true and grouped buttons can tell which window the sound is associated with, then it sounds like it is essentially a trivial oversight or bug that when the buttons aren't grouped, it does not differentiate. No new infrastructure is needed; the necessary information is already there.
(In reply to Nate Graham from comment #46) > This is a bug report generator, source of frustration for users, and black eye for us in YouTube reviews. That is not good. It sounds like it should be disabled by default, or something like that, until someone can get it to work at least with ff and chrome. I guess many of those users are probably coming from Windows. I wonder if anyone at KDE/gnome/freedesktop/other interested parties has any sway with chromium, to get them to start stamping their audio with metadata that could be used for this? One possibility is that chrome's profile could be read directly. I know it's possible to get info from firefox's session like this. Kinda hacky though. (In reply to Bharadwaj Raju from comment #45) > When the windows *are* grouped, in Firefox, the playing audio icon only > shows on the thumbnail of the one playing the video *if* it's open to the > same tab. Seems like it's already matching the media.name of the stream to the window title (which comes from the active tab's title). If so, one half of my browser integration plugin idea is already there. We just need a means to match tab titles to windows, for those times when the relevant tab is not the active tab.