[RESPONDED] Video playback broken depending on Audio output device selected

Totally losing my mind on this one if anyone has any advice for making sense of this.

Every time I open a new video stream in firefox the video will freeze/stutter at about 1 fps with no audio output. I can fix this by switching to “HDMI - Display port build- in audio” output → then the video starts playing normally, then I can switch back to “Speakers - Built in Audio” and the audio will start playing alongside the playing video.

Running Fedora 36 Gnome mostly default everything.

The background - I recently switched to an HDMI monitor that doesn’t have audio output so I’ve been switching back to the laptop speakers - seems simple enough but this was its own mess to figure out but eventually found GitHub - kgshank/gse-sound-output-device-chooser: Gnome Shell Extension to show a simple chooser to select Input & Output device based on gnome control center which worked (Trying to edit/discover outputs through pavucontrol and gpwgraph didn’t show all the outputs or work for me)

(As an aside - not sure when everything switched from pulseaudio to pipewire but I’m only an audio engineer/audio programmer on the occasional weekend every 4 years so not surprising I have no idea when this happened or what the actual difference is - nor did I really care to find out…)


It’s obviously frustrating to have to switch audio output every time I stream a video not just to fix the audio but to fix the video stream but honestly I’m just perplexed that this is even a possibility - how does the audio output device I’m using impact the streaming video and why is there a bidirectional impact on that from something that should be completely independent of the video/audio stream playback.

Not sure what’s going on with audio in linux, but this seems like a complete mess. Not sure I expect much help here and am kind of just venting due to the sheer insanity this experience is causing trying to figure out what is going on. How is an average user supposed to make sense of this dumpster fire? Sadly I really have gotten to the point where I can’t recommend linux to people and its because of things like this, any guidance/input/explanation would be useful, I don’t think I understand the audio systems in Linux enough to really navigate it and the forum/troubleshooting searches about these systems just brings up a lot of older information that isn’t relevant and will likely break everything worse due to the mix of standards and interface layers that are masquerading about.

Quick check: are all the codec packages installed? For some reason my Fedora install didn’t have them all and I’d have seemingly random playback issues because YouTube chooses to store random videos in arbitrary encoding formats.

Thanks, spot checking a few streams and that may be the cause, hasn’t happened yet and was happening pretty consistently before.

Just followed this guide:

No idea why it was working before without any issue before I switched the audio output, or why switching the audio output device would have fixed a missing codec issue but must be something firefox is doing negotiating the stream behind the scenes depending on the downstream audio output sink.

1 Like

Spoke a little too soon, but does seem like it isn’t happening as often after updating all the gstreamer/multimedia plugins.

Still have to switch to HDMI audio and back to fix the video playback stuttering but seems like it’s only happening occasionally when opening new live streams or when I mute-unmute even if the playback was working fine before I muted the audio.

So it must be an intermittent firefox/multimedia codec/pipewire/gstreamer-plugin/pulse-audio-interface-plugin-layer/virtual audio sink/Kernel/OS/gnome/gnome-python-audio-extension/wayland/hardware audio card/hdmi cable (should have got that gold plating) negotiation issue, seems obvious now at least.

It does seem like Pipewire is going in the right direction now that I kind of know what it does and replaces.

Hi @Will_C You’re on F36, correct? We recommend running one of the supported releases as a LOT of changes have taken place. Ideally, Fedora 38 is going to be my recommendation. Pipewire is the default there and it runs very well.

Pipewire completely replaces Pulseaudio, however, it’s Pulseaudio application compatible. So I’d recommend having the Pulseaudio Volume Control installed as it will give you ample control what is going where in terms of where applications are sending audio.

If it was me and without knowing what changes were made with your older F36 install, I’d give 38 a try, install the correct codecs, then install and utilize Pulseaudio Volume Control (pavucontrol.x86_64).

If you would rather stick with F36, you may try some of the re-installation suggestions found here. Fedora Audio Troubleshooting Guide

Thanks Matt, it’s mostly manageable now but I appreciate the information. I agree I should probably update to the latest version to get better support, I’ve been meaning to for a year or so but with everything running smoothly until now there hasn’t been a reason to.

Beyond the initial frustration I was kind of just perplexed by how/why this was happening but the pieces are kind of coming together.

My currently working theory has something to do with the way the pulseaudio/pipewire-pulse layer sets up the default sinks with the linux soundcard drivers. For reference, the soundcard/ALSA drivers have hdmi and the built-in laptop speakers as actual output profiles/devices.

It’s still not clear to me what triggers one of these code paths with an audio/video codec that causes firefox to modify the sinks with its pulseaudio library, but it appears to revert to the HDMI sink even though pipewire-pulse has already disconnected that (which is being controlled by the gnome-python-extension - which is also using a pulseaudio library but may be making changes in ways that break the current sink discovery in the pulseaudio layer)

At this point firefox must be sending the audio stream to the HDMI sink where some kind of media video/audio buffer synchronization occurs in firefox - I assume an audio buffer callback is timing out which eventually freezes up the entire multitrack media playback stream. Based on the video frames that are still received we can kind of determine what that timeout must be.

Anyway, when I switch back to the hdmi sink it must reconfigure the pulseaudio streams and start clearing the buffer again, allowing these buffer callbacks to succeed, which allows the multitrack media synchronization to occur which causes the video stream to start playing back normally (but still no audio since it is going to hdmi monitor with no speaker), and then, finally when I switch back to built in audio on the laptop, pipewire-pulse takes all the previous audio streams and pipes them back into the correct audio output device so everything appears to be operating normally until we run into this situation again.

No idea what initially causes it or why the video/audio codecs come into play but maybe firefox causes some kind of re-initialization of the audio layer for some codecs. Either way it does appear that better codec support significantly fixed the issue for youtube videos at least.

Sanity partially restored, I think.

1 Like

Interesting. Might be fun (and harmless to test with) running another browser unrelated to Firefox. Could also be interesting to leave journalctl -f running to see if anything pops up in real time that sheds some light on things.

In any case, glad it’s cleared up for you.

@Matt_Hartley, I’m having the same issue on Mint 21.2. Often video playback will freeze altogether until I change my audio output from Analog Output to Digital Output (S/PDIF), both going to my Behringer UMC202HD. Also using Firefox (118.0). I haven’t tested it on other browsers. Sometimes it will allow me to switch back to analog and playback will work fine, other times I have to stick to digital, or whichever one is choosing to work at that time.

Welcome to the community @C_T

I put some things in bold as they stood out to me. I haven’t used my external audio gear for sometime, however, some stuff you indicated stuck out to me.

Using PulseAudio Volume Control (install pavucontrol via apt), in the configuration tab, when you change it to Digital Output, this does work as expected, correct? Is there reasoning why you prefer it not to be set to Digital Output? Again, don’t have anything like this in front of me at the moment, so I want to make sure I am following.