Firefox doesn't close unused Pulseaudio sinks on Linux
Categories
(Core :: Audio/Video: Playback, enhancement, P3)
Tracking
()
People
(Reporter: noxphasma, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Steps to reproduce:
Watching videos on pr0gramm.com.
- Go to https://pr0gramm.com/top/kadse%20video/3555620
- press the Right Arrow key on your keyboard to load the next video
- watch the Sink amount raising in Pavucontrol
Actual results:
Firefox opens for each audio/video with audio source a new Sink in PulseAudio, but never closes the Sinks on idle. Finally Firefox can't play any new audio/video files due to not being able to create new Sinks. The only way to get rid of the Sinks is to either reload the page, close the Tab or restart Firefox.
Expected results:
Firefox should close idle Sinks and reopen them on demand. Or use only one Sink for each tab, like Google Chrome does.
|
||
Comment 1•5 years ago
|
||
Hi,
Thanks for the details.
I was able to reproduce the issue on the latest Firefox Nightly 73.0a1, and on Firefox 71.0 on Ubuntu 18.04.3 LTS (64-bit).
I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.
Best regards, Clara.
|
|
||
Updated•5 years ago
|
|
||
Comment 3•5 years ago
|
||
I've using the STR above, I see that they are collected after some time, but we still use a lot. I don't quite understand why there is a limit in pulseaudio sinks count however.
We should be more aggressive at closing them, but if the javascript doesn't release the media element, should we kill the AudioStream? Unclear.
I don't quite understand why there is a limit in pulseaudio sinks count however.
Because of programs like Firefox which open countless sinks, this is not normal behaviour and shouldn't.
|
|
||
Comment 5•5 years ago
|
||
The limit doesn't make anything better.
It's been some time I've worked in the area, so I don't really know what's up, but I suspect the website doesn't dispose of their HTMLMediaElement. We should be more aggressive with closing AudioStream objects for HTMLMediaElement that are not playing anymore. I'm pretty sure that this bug is present on all platforms. Or at least something similar in effect is happening on Windows.
Alex, do you think the changes in bug 1571513 will affect this? I'm moving this to p3 as it's unclear to me how we action this, but would appreciate your input.
|
||
Comment 7•5 years ago
|
||
I'm finding it very hard to figure out which tabs of mine are causing this issue. But none of them signal that they are in playback, yet the pulseaudio input sink from firefox reports that's it's in the "RUNNING" state. Surely it should be in the corked state if there is a media element around that is not currently in playback.
|
||
Comment 8•5 years ago
|
||
No, it does not look the same. I believe that the old media element stays around but I need to verify that theory. If I refresh the page the old elements are collected after ~10sec. I'll try to find more information about it.
|
|
||
Comment 9•5 years ago
|
||
I see from the logs that the media element is removed from the tree but it remains alive. I am not sure if this is a fault of the page. Nevertheless, from Firefox's point of view, if we want to prevent that kind of error, we could suspend the MediaSink when that happens.
|
|
||
Comment 10•5 years ago
|
||
I have created a patch that suspends the element when it is removed from the tree. That appears to solve the problem. I need to make the patch more elegant since it makes use of a flag to recognize the first time it is added in the tree in order to avoid calling Resume on a non-suspended tree.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=bf62d1ededce2bf72d6d2d4e5f26a68ebc0bf136
|
|
||
Comment 11•5 years ago
|
||
|
||
Updated•2 years ago
|
Description
•