PipeWire 0.3.62

The easiest solution is to use your computer's accurate clock to time the frames. This means, if your video is at 30 FPS, you will have gone through exactly 3000 frames after 100 seconds. But your monitor might not be refreshing at exactly 60 FPS, it might be targetting the 59.94 standard, or it might be targetting 60 FPS but with a clock that's a bit less accurate than your computer's, so every now and then, you get a stutter as a video frame has to shown for 1 refresh interval longer or shorter than it should.

What we could do instead is to calculate a fixed pattern to display frames. If your monitor is 30Hz and the video is 30 FPS, we show exactly one video frame for every monitor refresh. If your monitor is 60Hz and the video is 30 FPS, show each video frame for 2 monitor refreshes. If the monitor is 30Hz and the video is 60 FPS, skip every other video frame. This will already introduce some deviation from the "ideal" timing if your display clock isn't super accurate. And if the monitor is 59.94Hz, that's probably close enough to 60 that we want to show each frame of 30 FPS video exactly twice, but that means the video is playing at 99.9% of its intended speed.

10 seconds over 20 minutes is a surprisingly big gap though. Playing every frame of 30 FPS video twice on a 59.94Hz monitor would net a 1.2 second deviation over 20 minutes.

EDIT: Why the downvotes? Everything here is correct according to my understanding of the situation after implementing video playback software and working with other people's. If anything is wrong, please correct me, don't just silently downvote.

Use Pipewire then. As other have said, this is not a problem anymore with the recommended setup of Pipewire + WirePlumber.

2060: PipeWire11 is being deprecated and replaced with a compositing audio server named Weyband

If anyone is dual-booting Linux and Windows, here's a gotcha to keep in mind: Bluetooth pairing works using keys associated the MAC address of a Bluetooth interface. If you pair a device on Windows (key A) and then try to pair/connect to the same device after booting into Linux (key B), it simply won't work without anything telling you the real reason: To the device it looks like someone is impersonating the host interface, since it was previously set up using key A, but suddenly someone (Linux) pretends to be the same host (MAC address still the same) but with key B. The solution is simply looking up the key in the Windows registry and then using the same key in Linux.

Unfortunately, the process is a little complicated, but the Arch wiki page [1] does a really good job of explaining this nowadays. I've previously tried to set this up a few years back, but it didn't really work. Perhaps the wiki page was expanded in the meantime, or I simply did something wrong back then.

Just posting this here hoping I might be able to help some people wondering why the hell some of their devices just don't want to connect on Linux.

By the way, AFAIK some devices just don't care about the keys, that's why you might only have issues with a subset of devices.

[1] https://wiki.archlinux.org/title/Bluetooth#Dual_boot_pairing

How is that "better than pulse ever did"? The only issue I had with PulseAudio on several machines in last decade or so was Bluetooth A2DP connection being very capricious.

I have recently switched to PipeWire and it actually improved Bluetooth, but I had to disable Wireplumber's libcamera backend because it made it regularly eat 100% of RAM. No complaints after doing that. Crackling noises or desynchronized video playback would instantly take it into "unacceptable" territory.

Sounds like you have severe issues with both PA and PW. Maybe your hardware is the problem?