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.
*** Bug 504234 has been marked as a duplicate of this bug. ***
most similar thing on the Mozilla Bugzilla; https://bugzilla.mozilla.org/show_bug.cgi?id=1249974 "Add "Mute Tab" menu item to Window menu" I've asked upstream about this issue; https://bugzilla.mozilla.org/show_bug.cgi?id=2015361
Full 9 years later and this regression is still not resolved.
(In reply to Dragan from comment #51) > Full 9 years later and this regression is still not resolved. Let me explain what's taking so long. We want to have the mute button appear only on "the window that's making the sound" that button would mute. "The window that's making the sound", is a thing that does not exist. The sound is not coming from any of the windows of your browser. *All* of the sound from the browser is coming from *one* process that the browser spawns, that just plays sound. When a tab in a window wants to play a sound, the tab asks that sound process to play it. The tab in the window doesn't play sound. The sound process *just* makes sound, and doesn't even have a window. So, to solve this, we need some magic that tells us what sound comes from what window. The sound server (pulse, pipewire) can be given a way to identify the window, by the browser. If the browser does this, KDE can make the UI work like you want. Browsers do not do this, so KDE can not make the UI work like you want. In firefox, that process sets the title of the tab that's playing the sound, but still does not tell us which window has that tab. We could maybe find that window from the tab title though, so there is some hope, but it would be hard to code and require an extension. In Chromium, that process sets nothing and there is no data for us to know which tab in which window is playing which sound. There is no possibility that it can ever work like you want on chromium, until they fix this. So KDE can't fix this. Firefox and Chromium need to fix this. I understand that it's frustrating for you, and I am trying to help you to get it fixed. It can't happen here, KDE can not do it. Chromium must fix it. Firefox could improve things, too. But really, this whole thing is blocked by chromium. BTW, firefox has had broken volume control on linux for 15 years and they have the extremely simple 1 line patch to solve it for 5 years and still haven't merged it. Browsers aren't fast to fix things, even if you do it for them. Expect this to never work like we wish it did. I'm sorry to be the bearer of bad news. But if you do want to fight for it, fight in a chromium bug report. All we can do here is wait until someone does that.
(In reply to pallaswept from comment #52) > Let me explain what's taking so long. It's not a jab at KDE team, it's simply frustrating that a feature that used to work is no longer there. Did anyone manage to figure out what did Firefox and Chrome change, seemingly at the same time?
(In reply to Dragan from comment #53) > It's not a jab at KDE team, it's simply frustrating that a feature that used > to work is no longer there. Sure is. > Did anyone manage to figure out what did Firefox and Chrome change, > seemingly at the same time? They both changed from the old way of generating sound, where each window had it's own sound handling (so, the process ID that was playing the sound, and the process ID of the window showing that tab, were the same ID, so KDE could match them up), to a central sound process that handles the audio for all the tabs and windows. This was part of an overall change to how webpages are handled, where each page is running in it's own separate process, sandboxed from the others for security. I had to ask a search engine for the dates, but I'm pretty sure this is correct: That was enabled by default in firefox 49 (e10s) in September of 2016 and Chrome 76 (Audio Service) in July 2019. Basically it happened ~roughly~ around the same time because there was a general industry push for better security in webpages. What's really frustrating is that on windows, both browsers send the necessary metadata to the sound service, to identify which process ID is associated with a sound stream (ie, which window is making that sound). They just don't do it on linux. For history, you can read about where they added metadata handling to firefox, here: https://bugzilla.mozilla.org/show_bug.cgi?id=965653 Basically, it just never occurred to anyone there, that we'd want to identify the window playing the sound. The audio engine which firefox uses, cubeb, also does not have any facility to receive such metadata. They only have a field for the audio stream name (usually the tab title). So, we'd have to get firefox AND cubeb patched. As I mentioned before, they're infamously bad at this, even for critical and simple things like setting the volume. To be really frank, when it takes more than 5 years to merge a single line patch to fix every single linux user's volume control, it really feels like they just don't care at all. I sincerely hope a cubeb dev arrives here, merges that patch, and tells me I am wrong and an idiot. We should give up hope of this being fixed until a lot more people migrate from windows and complain to the browsers about this. When the browsers start to care a bit more about audio on linux, we might see some improvement. I'm just trying to direct the frustration that we are all feeling in this thread, to a productive place.
> merge a single line patch to fix every single linux user's volume control Just of curiosity, do you have a link to the corresponding MR/PR? Thanks!
(In reply to postix from comment #55) > > merge a single line patch to fix every single linux user's volume control > Just of curiosity, do you have a link to the corresponding MR/PR? Thanks! https://github.com/mozilla/cubeb-pulse-rs/pull/75/changes#diff-4e446a2e6b4bdb3c1be55ef9b44ec4a2b1c04c15865a0fde7680d342b065a36aR760 To explain myself, yes, there are 5 lines of code, only 1 is actually critical, the rest is just 'correctness' because the person who wrote it was being thorough. I forgot all that was there. The important one is the line I linked. Highly recommended. It's nice to have your volume the same in firefox as in plasma-pa and plasma OSD :)