within firefox - playing back media on youtube (or loading discord in firefox) - yet another bug report for freezing / hanging / crashing
- PipeWire version (
pipewire --version
):0.3.43
- Distribution and distribution version:
ubuntu 21.04
- Desktop Environment:
budgie-desktop 10.5.2
- Kernel version (
uname -r
):5.15.32-xanmod1-tt
Description of Problem:
The (yet another) return of the bug you thought was solved! Firefox youtube hanging or messing up. Refusing to play videos. Also discord website freezing up firefox. etc.
How Reproducible:
Often you cannot see or reproduce this same issue. However what can tell you, is that on my setup, it has the following specific peculiarities, which do seem to have a bearing upon things:
- Firefox version
96.0
- WebRTC is disabled in the browser (for tighter security)
- XOrg based desktop environment (NOT wayland)
Today have discovered that in the above modes, firefox is using a fallback to pulse audio. Even though pipewire might be supported now in firefox? That is only? If webrtc is enabled and if it's running under wayland. Which my configuration definately isn't
Steps to Reproduce:
Firstly, the user might need to have the same configuration circumstances as above ^. Because it might not occur under other configurations such as native wayland etc.
- Edit the config file
~/.config/pipewire/pipewire-pulse.conf
- Enable the non default setting
node.autoconnect = false
within thestream.properties = {
block at the bottom of the file - Restart systemd services
pipewire-pulse
and thenpipewire
- Reopen firefox or reload the browser tab with a youtube video in it
- Play the youtube video, and observe if the bug occuring
If the bug is happening, then the timer on the video will not be moving. And the video will not start playing immediately. Instead the video may start to play later on, however if it ever does start to play then there will be no audio.
Another symptom of this bug is that firefox may start freezing intermittently for a number of seconds. And then temporarily un-freeze itself. For a few seconds. And then completely freeze and lock itself up again. In a continual cycle. This cyclic freezing will continue until the user can manually close the tab containing the youtube video. Once the youtube tab is closed then firefox will typically stop misbehaving like that. (until the next time you try playing some more youtube videos).
Furthermore if firefox has been open for a long time (several days). Then the freezing issue will typically become much more severe. And occur to a greater extent. Until firefox becomes almost completely unusable.
OR (alternative bug, but it's realy the same exact bug here)
Just loadup discord website, login and go about navigating the chat rooms. Discord will in the background be trying to setup all sorts of pulse audio streams (for microphone, chat audio and other chat sound effects or notification sounds etc). And this will then also lockup firefox and cause it to freeze a lot. Or to create a situation where it may crash the browser.
This seems to be occuring when firefox is in pulse audio mode AND when node.autoconnect = false
. But only for in pipewire-pulse.conf
.
So it is specific to pulse audio clients only. Therefore perhaps some similar type of issues might indeed also occur somehow in other pulse audio clients. But clearly firefox is the easier application of choice here, for trying to reproduce this specific bug.
Why I am asking for this bug to be fixed:
So why not just remove the config setting to avoid this bug then?
I have a desperate compelling need to set the option node.autoconnect = false
for all the audio engines (all my client apps), so to stop them from always automatically connecting and routing to the wrong device output. This is a super annoying behaviour, most of all because there seems no good or reliable methods to actually control which specific default device that all the audio gets routed connected to. For example i have these random cheap game controller USB dongles, that then the system chooses for me as being 'THE SOUNDCARD' of my PC. And then everything tries to auto connect to that stupid $5 usb dongle. What i want the target default destination node to be is my DAW software. However it turns out that: I cannot do this important critical thing. At least with this specific autoconnect
feature of pipewire.
So I must disable this autoconnect feature. At least until such a time that pipewire's autoconnect feature can be improved upon. However that might happen.
Upon seeking advice on matrix, I have been told by someone else (who is much more knowledgable than myself) that it cannot in fact be made to work with any DAW, because a DAW is a software app. This is no good! Because everything first must pass into my DAW for processing. And not directly out to the hardware. No good!
For the time being at least I need to instead resort to a 3rd party helper program. Such as qpwgraph
to store and remember / save all of my node connections. And then automatically watch and restore them, doing the correct routing between graph nodes. To reproduce the feature and get new connections to go to my DAW program.
Perhaps alsa can instead be configured at a lower level to pretend and masquerade a dummy virtual alsa device, to pretend that is a hardware soundcard. But that is something else entirely far beyond my own understanding. And just impossible to configure and get working properly (i tried). But even if that part of it worked, pipewire is still be autoconnecting to the wrong soundcard anyhow. Which is another different problem with the autoconnect feature that I still absolutely cannot fathom how to change that behaviour whithin pipewire system. It just all seems either way too difficult? or not documented? or not implemented yet?
So that explains is why i need to use the feature node.autoconnect = false
. At least for the time being. And cannot just simple disable this setting to avoid this bug from happening.
Additional Info (as attachments):
It should be noted that I have today tested and reproduced (both positively and negatively) this bug on my system. And have double checked that is manually set now node.autoconnect = false
in all of my OTHER pipewire config files (for native clients, realtime clients, main config default setting, and in jack clients). They all have the autoconnect disabled except for the pipewire-pulse.config
. When flicking it between true and false to reproduce the issue. Gets both a positive and negative test result. And without changing absolutely anything else on the whole system.
So to be clear it seems specific to pipewire-pulse. Or just pulse clients only. At least here on my system.
If you need further details then please request. Have not included any log file yet because I was too busy getting a decent bug report down. But perhaps you need certain logs, or maybe other additional information that is not included in the default pipewire logs. Then please reply and ask, then I will try my best to provide what you need. Many thanks (and sorry for not providing logs just yet).
Other possible related bugs (not verified)
Thought it might be helpful to collect other open issues which might seem to have similarities. In case of any duplicates. This does not mean that all of these listed bugs are definately duplicates. It is also likely that some of them are not related to this bug, they just seem a bit similar looking:
@wtaymans PING