Fedora 34 KDE - unstable vsync-ratio and delayed/dropped frames in mpv
Version, Distribution, Desktop Environment:
- Fedora 34 KDE (clean install, not upgraded from 33)
- Kernel: 5.11.20-300.fc34.x86_64
- KDE 5.21.5
- kwin 5.21.5 (using X11)
- 1920x1080 60Hz
Description of Problem:
ao=pulse with any of the display type options for video-sync (video-sync=display-resample is what I'm targeting), vsync ratio will fluctuate by up to +/- 0.020 of the expected value every few seconds. This comes with one or more mistimed frames for 24 fps videos, and some dropped output frames for videos over 30 fps.
Starting a video with the pause option on any video-sync option, waiting a few seconds, then playing causes the audio to not play back. The above problems still occur. The audio bitrate still updates on the stats page when this happens. Pausing/playing or seeking fixes it.
alsa-monitor.conf. Setting to 0 resolves it.
ao=alsa has it much worse, with vsync ratio fluctuating every second. Mistimed frames build much faster, dropped frames as in the above case much faster, and even 24 fps videos start dropping output frames.
This may be a regression in alsa-lib from 126.96.36.199-5 to 1.2.4, but 188.8.131.52 through pulseaudio still suffered for me on Fedora 33 KDE live.
This seems to be fixed for the most part with alsa 1.2.5-2?
Vsync ratio holds more stable, very rarely deviating by 0.010. Jitter mostly holds 0.000. But occasionally seems to go to 0.001. Either of these still seem to sometimes mistime a frame.
ao=sdl works fine, no dropped frames and only a couple mistimed frames on playback start.
ao=jack works the same as sdl, but causes the audio in mpv to stop for a second and mistime a frame if say, something else plays a ding in the background.
I realize using live media for testing things is not ideal, but I still tried with it. Boot up, enable rpmfusion, and download the multimedia group and mpv.
Fedora 33 KDE live for pulseaudio,
ao=pulse worked flawlessly. The problem where sound doesn't play from above also doesn't occur.
ao=alsa had the same problems as my install with Pipewire however.
Fedora 34 KDE live. This is a strange one. The first time I tried, ao=pulse seemed to be fine with pipewire 0.3.25. Updating Pipewire packages to 0.3.27 and doing
systemctl --user restart pipewire.service pipewire-pulse.service complained that I should restart the daemon service first but did it anyway. The issue with ao=pulse arose again. I restarted and tried again from the top, but couldn't get it to play normally with pulse on 0.3.25 after three more attempts. Either I wasn't paying enough attention on that first try, or there might be something between 0.3.25 and 0.3.27?
ao=alsa was still terrible in any case.
After all that, back on my install I tried clearing /etc/pipewire & ~/.config/pipewire, downgrading to 0.3.25 and restarting, but it didn't make any difference.
One last thing, but I don't know if it has any bearing. I noticed that on the archwiki page for Pipewire, it says in the No devices detected after PipeWire update and reboot (git / >=0.3.23) section that pipewire-media-session is now a service. But on Fedora, they're still running it inside of pipewire.service on 0.3.25 and 0.3.27.
Failed to enable unit: Unit file pipewire-media-session.service does not exist if I try starting it.