I noticed on my Rawhide system, pipewire-pulseaudio seemed to be consuming a lot of CPU time, all the time. pavucontrol showed two 'speech-dispatcher' 'dummy' things outputting audio all the time. So I removed speech-dispatcher-espeak-ng , speech-dispatcher , espeak , and espeak-ng - which took orca along - and killed those processes, and pipewire-pulseaudio seems to have calmed down a bit now. But orca is installed by default, so I think this probably happens on a default install. I don't think pulseaudio itself used up so much CPU time for them. I'll try and test this on a live boot or something on Monday, but wanted to file it for now.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
I wanted to add that I've been seeing similar issues with speech-dispatcher and PipeWire on Fedora 33 (with pipewire-pulseaudio replacing pulseaudio). After a while, I will get a lot of crackling and stuttering in audio (usually with Firefox open), and the error log is complaining about speech-dispatcher. Killing speech-dispatcher in System Monitor fixes the crackling/stuttering. It seems to have been documented upstream here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/399 And here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/529 But both of those issues were closed without a clear resolution.
Switched to f34 a few days ago and sometimes I see constant high CPU load (about 12.5 % according to top) from pipewire was well. Seems it's caused by speech-dispatcher as well, see pw-top output below for details. The problem only shows up after using my machine for a while and seems to be triggered by playing YouTube videos in Firefox; once I close Firefox the CPU load goes down to a normal level (I tried once to simply close all tabs and it didn't help). ! 28 0 0 0.0µs 0.0µs 0.00 0.00 0 Dummy-Driver ! 39 0 0 0.0µs 0.0µs 0.00 0.00 0 Midi-Bridge ! 45 0 0 0.0µs 0.0µs 0.00 0.00 0 v4l2_input.pci-0000_05_00.0-usb-0_2_1.0 ! 47 0 0 0.0µs 0.0µs 0.00 0.00 0 v4l2_input.pci-0000_05_00.0-usb-0_2_1.2 51 64 48000 101.6µs 2.4µs 0.08 0.00 47 alsa_output.pci-0000_06_00.6.HiFi__hw_Generic_1__sink 49 110 44100 46.4µs 27.7µs 0.03 0.02 47 + speech-dispatcher-espeak-ng 86 110 44100 74.0µs 12.7µs 0.06 0.01 47 + speech-dispatcher-dummy ! 52 0 0 0.0µs 0.0µs 0.00 0.00 0 alsa_input.pci-0000_06_00.6.HiFi__hw_acp__source ! 53 0 0 0.0µs 0.0µs 0.00 0.00 0 alsa_input.pci-0000_06_00.6.HiFi__hw_Generic_1__source Let me known if there is anything I can do to track down the root cause of this, then I can try to give it a shot the next time it happens (not sure yet if I can trigger it on at will).
Speech dispatcher requests a rather low latency and so the CPU load will go up. you can switch it off with: media.webspeech.synth.enabled and firefox about:config 0.3.23 forces higher latency on speech dispatcher and might be better. Here is the update for f34 https://bodhi.fedoraproject.org/updates/FEDORA-2021-9ac0a0a93a
(In reply to Wim Taymans from comment #4) > Speech dispatcher requests a rather low latency and so the CPU load will go > up. > > you can switch it off with: media.webspeech.synth.enabled and firefox > about:config Might try that, but allow me a question: why is Firefox starting the speech dispatcher at all after a while and continues to use it even after I closed all tabs? Isn't that the part problem here (and will become a problem for battery life)? Should we thus file a Firefox bug as well? Disclaimer: I don't know much about this whole stuff, and thus are by question and what I'm implying might be totally off track, but I just had to ask... > Here is the update for f34 https://bodhi.fedoraproject.org/updates/FEDORA-2021-9ac0a0a93a thx!
> Might try that, but allow me a question: why is Firefox starting the speech dispatcher at all after a while and continues to use it even after I closed all tabs? Isn't that the part problem here (and will become a problem for battery life)? Should we thus file a Firefox bug as well? I have no idea, and indeed for battery life this is bad. Maybe file a bug for firefox, yes.
(In reply to Wim Taymans from comment #6) > I have no idea, and indeed for battery life this is bad. > Maybe file a bug for firefox, yes. FWIW: Done, see Bug 1936901 for details.
FEDORA-2021-2c994d0609 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-2c994d0609
FEDORA-2021-2c994d0609 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-2c994d0609` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-2c994d0609 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-2c994d0609 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.