Description of problem: Here firefox (or something in Gnome 40?) sometimes spontaneously seems to enable & use speech-dispatcher for some unknown reason leading to unnecessary CPU load. The speech-dispatcher according to pw-top continues to run, even if I close all tabs and disable all extensions at run time; a "about:performance" doesn't provide any hints what might cause this. Only way to make it stop: restart firefox. That is partly a problem with pipewire, which is discussed in Bug 1925810. But it seems there is a bug in Firefox as well, as I have no idea why it sometimes enables speech-dispatcher after browsing for a while (sometimes it takes hours; seems it often happens after or while I'm visiting YouTube). I'd appreciate a few hints how to track the root cause down so it can be addressed; that's IMHO worth it, as the CPU load is bad for battery life (and makes my Laptop's fan run constantly – otherwise I wouldn't have noticed the problem) Version-Release number of selected component (if applicable): firefox-86.0-7.fc34
The speech service lives here: https://searchfox.org/mozilla-central/rev/5a66c4b4a41ab78a87c30c9db0d93c732c534402/dom/media/webspeech/synth/speechd/SpeechDispatcherService.cpp#313 I can't reproduce it, at least not on Fedora 33. I don't see the speech dispatcher at pulse audio volume control. Can you try to open the pavucontrol mixer, make sure speech dispatches isn't there and then launch firefox and look at pavucontrol mixer and check when the speech dispatcher appears? What do you do in Firefox to launch the the speech dispatcher?
(In reply to Martin Stransky from comment #1) > I can't reproduce it, at least not on Fedora 33. FWIW, this is something that started to happen after updating from F33 to F34. > I don't see the speech > dispatcher at pulse audio volume control. Can you try to open the > pavucontrol mixer, make sure speech dispatches isn't there and then launch > firefox and look at pavucontrol mixer and check when the speech dispatcher > appears? Right after starting Firefox it's not there. Sometimes I browse for hours and everything works, but then… > What do you do in Firefox to launch the the speech dispatcher? …after a while suddenly it's there and doesn't go away anymore (and creates CPU load all the time). It seems to be triggered by playing youtube videos somehow, but I haven't figured out how exactly. Will keep an eye on things, maybe I can find a reliable way to trigger it.
The speech dispatcher is issued when someone asks for it - maybe some page has some accessibility settings or so. You can also safely uninstall speech-dispatcher package if you don't need Orca screen reader.
(In reply to Martin Stransky from comment #3) > The speech dispatcher is issued when someone asks for it - maybe some page > has some accessibility settings or so. Ahh, okay. This helped be to find something that triggers it: I installed https://addons.mozilla.org/en-US/firefox/addon/read-aloud/ and simply let used to to read some a few words for me. Afterwards the speech-dispatcher-dummy continues to run forever and makes pipewire use ~3% CPU time and pipewire-pulse about 4% (according to top) constantly here until I close firefox. > You can also safely uninstall speech-dispatcher package if you don't need Orca screen reader. That's okay for me, I just feared it might be a general and hard to spot problem that would be annoying for others WRT battery life and fan noise. But yeah, maybe it's just something wrong/odd in my local setup here and not worth further investigation.
(In reply to Thorsten Leemhuis from comment #2) > (In reply to Martin Stransky from comment #1) > > What do you do in Firefox to launch the the speech dispatcher? > …after a while suddenly it's there and doesn't go away anymore (and creates > CPU load all the time). It seems to be triggered by playing youtube videos > somehow, but I haven't figured out how exactly. Will keep an eye on things, > maybe I can find a reliable way to trigger it. FWIW, I found it: visiting Rotten Tomatoes triggers this (even with a test profile a I created just for this).
(In reply to Thorsten Leemhuis from comment #5) > FWIW, I found it: visiting Rotten Tomatoes triggers this (even with a test > profile a I created just for this). I see, Thanks. Not sure why that page needs it :)
(In reply to Martin Stransky from comment #6) > (In reply to Thorsten Leemhuis from comment #5) > > FWIW, I found it: visiting Rotten Tomatoes triggers this (even with a test > > profile a I created just for this). > I see, Thanks. Not sure why that page needs it :) Yeah, no idea :-D FWIW: I rechecked with firefox-87.0-2.fc34.x86_64, the problem is still there on my mail work laptop (Ryzen 4000). I could also easily reproduce the problem with a second laptop (Intel Kaby Lake) where I freshly installed Fedora 34 ~2 weeks ago. Either I'm just unlucky or this is something that happens to more people, but they don't notice it. For me the additional CPU cycles burned due to this make the difference between 'laptop fan inaudible most of the time' and 'I can head the fan all the time'...
Still present in firefox-88.0-2.fc34.x86_64 (taken from koji) when running in wayland-mode with gnome-shell
Any news here? Still experiencing this issue, had to set DisableAutoSpawn in /etc/speech-dispatcher/speechd.conf to get CPU load down again :(
A workaround is to disable text-to-speech in Firefox about:config. media.webspeech.synth.enabled: false Works for me (on a different distro). Reference: https://www.reddit.com/r/firefox/comments/7n5vn6/linux_firefox_and_speechdispatcher_are_making/
I have this issue too, for me it's cause I have a download notification add-on that speaks when a download is complete. What add-ons are you using? Are you using pages that utilize accesabilty? I do think this is a bug and not because it uses CPU cycles. Keeping the lines open means no other programs can have exclusive control over the sound card. Why would you need exclusive control over the sound card? One use case that I do, is to have VLC take over the S/PDIF connection to do "S/PDIF passthrough" but I am sure they are other use cases as well.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This still happens in F36 (firefox-100.0-4.fc36.x86_64). Jamie (from comment 11) told me that it happens on F35 as well. @Martin or any other Firefox/Mozilla developer that might be listening: can we mere mortals do anything to help you fix this issue? It apparently happens to quite a number of people (and likely many others that just don't notice) and is really bad for battery life. :-/
For the record: - pipewire kinda documented the problem: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning - pipewire bug about this: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1968 They implemented a workaround to reduce the impact, but it looks like the real problem is somewhere else.
*** Bug 2035380 has been marked as a duplicate of this bug. ***
Frankly I have no idea. I don't see the bug on my end and I have zero experience with it. From the post it doesn't look Fedora specific.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.