sound (pipewire) stays active after a tab (discord) is closed
Categories
(Core :: Audio/Video: cubeb, defect, P3)
Tracking
()
People
(Reporter: mozilla, Unassigned)
References
(Depends on 1 open bug)
Details
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0
Steps to reproduce:
Using fedora 34 with latest updates.
URL used: https://discord.com/login
I logged into discord but did not do any activity. I see (in top) that pipewire became active
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
100766 eyal 9 -11 317308 41856 6704 S 4.7 0.1 113:55.84 pipewire-pulse
64810 eyal 9 -11 344036 19832 8004 S 2.3 0.1 55:30.94 pipewire
I then closed the discord tab.
Actual results:
pipewire stays active after the tab is closed. It stays active after all tabs (but one local file) are closed. It finally stops after firefox quits.
It looks as if firefox keeps pipewire alive and active when there are no tabs with sound.
Running in safe mode does not change this.
Using other sound applications (e.g. vlc) shows pipewire activated but then goes
back to zero CPU when vlc stops.
Expected results:
pipewire should have gone idle when the relevant tab was closed.
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
Tested now on Ubuntu 20.04 and same issue, except that it is pulseaudio that is kept busy.
Tested now on Ubuntu 20.04 and same issue, except that it is pulseaudio that is kept busy. FF 96.0.
|
||
Comment 3•3 years ago
|
||
Hi!
Taking into account the Description and regarding the last 2 comments, I'll mark this issue as New for visibility.
Still on fedora 34, now kernel
Linux e7.eyal.emu.id.au 5.17.4-100.fc34.x86_64 #1 SMP PREEMPT Wed Apr 20 14:41:56 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
and firefox
99.0 (64-bit)
Problem happens.
Still an issue with FF 100.0 (64-bits).
Is this issue getting attention?
Took a closer look. Now using the URL https://www.target.com.au
When I open target.com.au I see in puavcontrol Playback new items show up:
speech-dispatcher-espeak-ng: playback
speech-dispatcher-dummy: playback
speech-dispatcher-flite: playback
AT this point pipewire starts to consume CPU/
They stay after I close the tab.
They are gone after I restart FF and pipewire goes idle.
With https://discord.com/, after login, I see a fourth item
Firefox: AudioCallbackDriver
HTH
[could not find a way to edit my recent comment]
After closing the discord tab the "Firefox: AudioCallbackDriver" Playback stream disappears but the other three remain.
|
||
Comment 8•3 years ago
|
||
The three remaining streams are caused by epseak and are outside of our control. If you're not using it media.webspeech.synth.enabled to false in about:config will make them go away.
Thanks Paul, these are now disabled. FF sure has more settings than I will even know...
I now see pipewire activity when the discord tab is opened, but none after it is dismissed.
I am now on FF 100.0.2 .
Was this my problem all along? If so then this bug can be closed as "not a bug"?
|
|
||
Comment 10•3 years ago
|
||
afaik, it's a bug in espeak, that is used by Firefox if the website attempts to use the Webspeech API (that is often used for text-to-speech, for, say, accessibility). We don't have much control over this, but I haven't looked deeply enough I'm afraid.
I'm also working on making discord not use CPU for audio when it doesn't need to, but that's not finished.
I'm closing this, the work for Discord (but also lots of other websites) is going to happen in bug 1771179, you can follow along there if you're interested.
Description
•