All cores video stutters slightly with update from 4.0.2 to either 4.1 or 4.2
-
Problem: When I was running Retropie version 4.0.2, my 1080p output of all cores (NES, SNES, Megadrive) were flawless. Confirming via 240p test suite, the horizontal and vertical grid scrolling was smooth. When re-imaging to 4.1 or 4.2, and following the same configuration process, the screen stutters at random frame intervals in all cores, in all games, confirmed in 240p test suite. It is best described as 1 frame freezing every X number of frames. You barely notice it, but it gives this stuttering playback that makes it very difficult for me to enjoy the game I am playing.
My setup: I am using a Raspberry Pi 3, with the 2.5 power supply on my LG TV in 16:9 mode, with Game Mode on video and audio. I am wired ethernet to my network, and using a USB keyboard and a Buffalo SNES-style controller.
What I did to test: I spent 2 days extensively testing and re-testing this to make sure the problem is not something simple on my end.
I tried multiple NES cores, SNES, and Megadrive in both Retropie 4.1 and 4.2, and no matter my retroarch settings (core provided, custom, integer scaling, 1:1 PAR, 4:3, etc..) the stuttering happens. I then took that SD card and put it into another Raspberry Pi I have, with the same power supply and TV, and replicated the same results.
When I use my 4.0.2 image on either Pi, on the TV with the same settings, and any core, it scrolls smoothly, without any stuttering. I have all of the same settings that I manually set when I do a new image on both setups, so I am confident that this issue is something that happened with an update since Retropie 4.0.2.
I compared /boot/config.txt files and they are identical (other than commented lines). I was then going to compare /all/retroarch.cfg files across the two versions, but it looks as if they changed the style completely, so I am unable to do a diff.
Please guide me in the right direction, or let me know what I can provide to be of more help.
-
I took a short video to demonstrate this. It is very hard to record this stutter, and you can definitely see it better in person than here, but if you focus on either the foreground or the trees, you can see it happen a number of times in this short clip.
Note it is not screen tear caused from non-integer scaling, it is indeed some sort of video stutter.
-
Which specific emulators are you using? A lot has changed from RetroPie 3.9 to 4.2.
-
I mentioned the general cores above, but the specifics are:
lr-fceumm
lr-nestopia
lr-picodrive
lr-snes9x2010Because it is happening in all of them, I feel it must be something global. I am surprised that no one else has noticed or experienced this yet, as it jumps out to me like a sore thumb.
-
@dukesilver Did you try switching the video_threaded setting via configuration editor ? (or manually by editing
configs/all/retroarch.cfg) -
@BuZz On the newer versions, I used the configuration editor, and on 4.0.2, I manually edited the file, if my memory serves me. Do you think that could have any bearing on this?
I was doing some searching, and I did see another thread where someone saw stuttering in emulation station as well as cores, and he determined it was the Steam controller support drivers that were added in version 4.1 of Retropie, and by uninstalling them, it fixed his problem. I am going to give that a shot tonight to rule that out.
https://retropie.org.uk/forum/topic/7828/stuttering-issue-across-all-the-distrib/10 -
@dukesilver the steam controller drivers are not installed by default.
How you edit the file shouldn't make a difference, but some default options may have changed. Also make sure the video mode is the same between installs (
tvservice -s) -
@BuZz I will at least check my syslog per the steamcontroller thread, to see if there is any evidence of other errors being logged, that could be causing the stutter. He also used 'display framerate' to detect a frame dip ever X seconds, which is probably similar to what I am experiencing.
I just did a search for 'tvservice' in the entire 'configs' folder of both the working and jumping systems, and did not see it. Where is that setting stored?
-
@dukesilver that is a commandline tool to tell you the current screenmode.
-
@BuZz 10-4, I will report back.
-
I ran tvservice -s while inside of emulation station. I checked that video mode was left unset, shown by (), in each emulator at start. To verify I ran it again while in lr-nestopia, and it was the same.
On the stuttering install:
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressiveOn the working install:
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressiveI also verified that no steamcontroller drive is installed.
So, I will continue to investigate, and check the logs next, but as of testing both of these just now, one instance is stuttering, and one instance is working fine.
-
My investigation into the syslog did not find any obvious problems, but I do think there may be a larger problem with speed as a whole. I am hoping someone can try to replicate. Below testing is on the same pi, with the same 2.5A power supply, and the same 32GB Evo SD card, on the same TV.
On my working 4.0.2 build:
lr-nestopia runs flawlessly with a video_frame_delay of 6, as per Brunnis's recommendations for reducing input lag. No video stuttering in 240p test suite grid scrolling, or in games with scrolling such as Contra intro screen and Battletoads turbo tunnel.lr-snes9x2010 runs flawlessly with default settings. 240p test suite has no stuttering during grid scrolling, and Super Mario Allstars plays The Lost Levels without any stuttering or lag.
On my stuttering 4.2 build:
lr-nestopia runs well with default setttings, but a video_frame_delay of 6 make its stutter quite bad.lr-snes9x2010 produces HORRIBLE stuttering in the grid scrolling via 240p test suite, and Super Mario Allstars is unplayable during The Lost Levels, due to 1-2 frame freezing and lag. I can not beat the first level.
lr-snes9x2005 seems to be fine, with no noticeable stuttering.
-
No problems for me with Super Mario All-Stars playing the Lost Levels in Snes9x 2010 1.52.4 b2a69de
-
I played a bit more and I see some jitter for sprites, but only because I was overanalyzing everything. The game was still looking great and was totally playable.
How does it work "out of the box" with no video tweaks at all? I've done literally nothing to my two Pi 3s that are connected to TVs in terms of video settings aside from setting overscan and forcing HDMI audio, and they work great. It's sounding like you've "fiddled with the knobs" so hard trying to make a test suite run perfectly that now games are suffering.
-
@obsidianspider Tonight I will do a clean install of 4.2 and do nothing other than uploading the rom to verify, but all I did for last nights testing was set video_threaded to false and video_driver to dispmanx. No other changes were made, besides testing the video_frame_delay in the nes-specific retroarch.cgf file. Just to rule out any outside influence though, I will leave the video driver to gl and threaded video to true and see what that gets me.
For me, on The Lost Levels, it was stuttering so badly, that it was just not playable. Mario would freeze midair for 1-2 frames, every few seconds. If you didn't experience that, than there is something definitely going on with me changing the video driver or video threaded.
-
@dukesilver If there's a variable/setting you want me to confirm, let me know, but yeah, as far as I know, my stuff is default.
-
@obsidianspider Just to humor me, would you be willing to try dispmanx for video driver and video threaded to false.
-
@dukesilver oh yeah, dispmanx and threaded video off makes that game run like total garbage.
Running with just dispmanx as the driver makes it better, but it is a bit jerky.
Going back to threaded video on and gl as the driver is much better. Is it 100% perfect? No, but it's more than acceptable to me.
-
@obsidianspider Great for diagnosing the problem, crappy for me trying to reduce input lag. Brunnis discovered that changing to dispmanx from gl saves 1 frame of input lag, which is great. So it looks like something changed with the driver from 4.0.2 to 4.2. I may open up an issue in git at some point, but for the sake of this thread, after I confirm your findings, I think we can close this.
Thank you for working with me to help figure this out.
-
@dukesilver I've tried to minimize lag in the past and it ended up being a giant pain in the rear. I turned game mode off and went back to default settings. For most games it's totally fine for me. When I obsess over things like that I tend to forget what the heck I'm trying to do, which is play and enjoy these games. But I get it, I've been there. I spent around 30 hours trying to figure out why a kernel update broke a script to drive the second screen on my Super Famicom Pi.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.