Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Belarathon]

Hi there:

I have had an a/v sync issue with JRiver on Linux for as long as I've had it installed (maybe since MC25?).  MC always starts out perfectly synchronized, but if I FF or RW, I lose sync.  It's only like  1/8 to 1/4 of a second, but it's enough to be annoying.   I've tried:   Different audio devices (DACS), different renderers (pipewire, alsa, etc.) changed video cards from Nvidia to AMD, purchased a new monitor (ASUS - TUF VG27BQ), tried differing monitor refresh rates, tried different motherboard/cpu combinations, different distros...Debian Gnome...other Gnome distros, other desktop environments, disabling compositors and Vsync settings, different performance parameters for the video cards, including kernel mode, pipeline, etc.  An Nvidia GT1030 just didn't play nice at all, which I attributed to Nvidia's limited support for Wayland.  I'm running an R9 360 with FreeSync through a freesync compatible monitor  I've tried VGA, DVI,and Display ports.  It's nearly perfect in Wayland, though still have the same issue, just to a smaller extent. Incidentally, JRiver GUI response in Wayland  is superbly quick and smooth....even in KDE! I tried the a/v sync adjustments under video settings ,using both keyboard shortcuts and manually entering values....but it doesn't seem to help.

What else might I try?

Thanks!


Cary

[Belarathon]

I just realized that cpu and motherboard combos have been AMD of 2015 vintage, but never Intel.

[mwillems]

So I see the same problem with desynchronization on FF or rewind (using the left and right keys) on Linux and have forever (or at least for several major versions).  It is tied to the fast forward and rewind functions specifically; if you change your place in the video by leaving display view and clicking on the progress bar, there's no desync.  But it happens every time I jump forward or rewind with the left or right keys, especially if I use them several times in a row.  I've been working around it by basically fast forwarding to the place I want, stopping playback, and then hitting play again so it starts where I just was.

It's entirely hardware agnostic, I see it on intel, AMD, and nvidia graphics and four different machines of varying vintages.  I see it on both Debian Stable and Arch.  I think it's just a persistent bug in MC.  I assumed it was just me having the issue as no one else reported it.  I haven't tried fixing it with the a/v sync adjustment settings, because it was so obviously a transient playback related thing, but I'm not surprised that a/v sync adjustment doesn't fix it.

[Belarathon]

Wow...you mean I'm not alone, and I can stop flipping out needlessly?    Well, I wanted to make sure I did due diligence on my end, and deter "...no bro, it's just you; run Debian and everything will be copacetic."  Glad to know it's not just me. 
Perhaps this is an issue that can get some love during MC28 development.

While I have your attention, let me ask you if you have this issue under X11:

On a freshly booted machine; JRiver Theater Mode scrolling is very fast and smooth.  Then, in anywhere from just 5 minutes, to hours, or even days later, with no rhyme nor reason, scrolling becomes as slow as molasses, moving in slow, giant, juttery chunks. During the issue, resource usage is practically nil.  My troubleshooting measures regarding this issue have been the same as my original post.   This does not happen in Wayland.

[JimH]

Have you tried another X11?

[mwillems]

Jim, I've tried a few different X versions on Debian, but with no noticeable difference.  I've also tried running MC under wayland (via xwayalnd).  The desync seems to be pretty persistent in my testing.

Wow...you mean I'm not alone, and I can stop flipping out needlessly?    Well, I wanted to make sure I did due diligence on my end, and deter "...no bro, it's just you; run Debian and everything will be copacetic."  Glad to know it's not just me. 
Perhaps this is an issue that can get some love during MC28 development.

While I have your attention, let me ask you if you have this issue under X11:

On a freshly booted machine; JRiver Theater Mode scrolling is very fast and smooth.  Then, in anywhere from just 5 minutes, to hours, or even days later, with no rhyme nor reason, scrolling becomes as slow as molasses, moving in slow, giant, juttery chunks. During the issue, resource usage is practically nil.  My troubleshooting measures regarding this issue have been the same as my original post.   This does not happen in Wayland.

I don't have the slowness you describe in scrolling.  I generally see about the same performance in X11 and in wayland.  FWIW, MC always runs in X as far as I understand it, so it's just whether it's running in native X or in the xwayland compatibility layer.  I haven't really noticed any big changes in MCs behavior, but the only DE I run that has both wayland and X options is Gnome. XFCE is X only for now.

[JimH]

I've asked Bob and Hendrik to take a look at this thread next week.  Thanks for the details.

[Belarathon]

Thank you, kind sir!

As for a different X11, do you mean a different distro?  As far as X11,  I'm partial to KDE and I realize it's not supported, but at the rate Wayland is coming along under KDE development, it's practically a a bug-free, usable system.  That would make my X11 issue superfluous.  I just tend to flounder under Gnome.   

[Belarathon]

Jim, I've tried a few different X versions on Debian, but with no noticeable difference.  I've also tried running MC under wayland (via xwayalnd).  The desync seems to be pretty persistent in my testing.

"the only DE I run that has both wayland and X options is Gnome. XFCE is X only for now."

Fedora 34 KDE will now default to Wayland if you have an AMD card; up until only recently Wayland would pretty much crash moments later if you had Nvidia.
OpenSuse Tumbleweed gives the option of pure Wayland, Wayland X or X11.  If you want it in Arch, you have to install a few extras to get a session. 

[mwillems]

Fedora 34 KDE will now default to Wayland if you have an AMD card; up until only recently Wayland would pretty much crash moments later if you had Nvidia.
OpenSuse Tumbleweed gives the option of pure Wayland, Wayland X or X11.  If you want it in Arch, you have to install a few extras to get a session.

Oh I know KDE has a wayland session, I just don't use KDE regularly at all was what I meant.  I meant that I don't see any slowdowns in X under Gnome or in Wayland under Gnome or in XFCE. 

I do see the a/v sync issues in all three though.

[Belarathon]

After  a year searching the interwebs, I have found the solution for both a/v sync issues and choppy, juttery scrolling problems for X11 under KDE:
https://bugs.kde.org/show_bug.cgi?id=397850

The proposed workaround solves a host of other performance issues with KDE under X11.  Developers are aware of the bug, but have apparently chosen not to address the issue.  Subsequently, the issue exists to this very day on the most recent Plasma with all updates.

The workaround involves  disabling triple buffer detection in KWIN:

export KWIN_TRIPLE_BUFFER=0

Likewise, if you have an Nvidia card, disable triple buffering in xorg.conf:

     Option         "TripleBuffer" "0"

You'll notice that this is completely contrary to common wisdom across the internet.

Latency is now practically nil, my a/v sync is spot on, and my KDE "feel" of performance and has increased by orders of magnitude.

 Thinking my problems were an Nvidia issue, I switched to an AMD card - same issues!
 If you read the bug report, this issue also affects AMD cards. 
   

[JimH]

Thanks very much for posting that.  I added it to the Weird and Wonderful thread (link in my signature).

[Belarathon]

Thank you!