How's your input lag?

[MattRigg]

So I got RetroPie up and running, copied some ROMs over only to find that the input lag on my setup is horrendous.

To check that it wasn’t my TV causing the issue I made sure it was all set up correctly (HDMI input labeled “PC” and AV mode set to “Game”). Ran a quick 60fps counter video on my laptop (hooked up to the TV) and got the following;

1 frame = 16ms and from what I’ve read my TV has a 31ms lag, so this test seems about right.

However, when running the NES emulator I’m noticing an increased lag. For testing purposes I botched together a circuit consisting of a DPST switch with one set of terminals connected to a powered LED and the other set connect to the A/Ground connections on a SNES pad (which in turn is connected to the Pi via a SmartJoy USB adaptor). This means that when the switch is closed, the LED illuminates at *exactly the same time the jump button is “pressed”.

* or near as damnit!

I set up my camera to record 60fps and this is what I got;

The jumping animation doesn’t trigger until 9 frames have passed, deducting the 2 frames caused by my TV means that something (RetroPie/ES/emulator, or the Pi itself) is creating a 7 frame delay. Also tried a wired keyboard and a BT DualShock 3 and while I wasn’t able to test accurately (my PCB is literally hacked together and thus only works with the SNES pad) the lag ‘felt’ the same.

I also tried SMW on the SNES and got a slightly greater lag (jump triggered at frame 11).

I know input lag has been covered before but I’ve yet to find a solution that works.

Setup;
Pi 2 w/class 10 mSD and a decent PSU
Latest RetroPie (installed using script)
Overclocked using the “Pi2” setting in raspi-config

So my question is; what’s your setup and how is your input lag? Any suggestions as to how I can reduce this?

[ratsflif]

I’m interested in this as well. I haven’t run any test but quite a few games feel like there is some significant input lag and trust me, I’m not an input/display lag Nazi like some.

[jeffdamann]

You sir, have conducted one of the best inout lag experiments I have ever seen, Why did I never think of hooking an led into the button circuit and then sit it in front of the tv and record.

Applause my good sir.

[MattRigg]

[quote=113217]You sir, have conducted one of the best inout lag experiments I have ever seen, Why did I never think of hooking an led into the button circuit and then sit it in front of the tv and record.

Applause my good sir.

[/quote]

Thanks, although it wasn’t my idea; that magnificent bastard Ben Heck created an input monitor for an X360 pad (YouTube). I just hacked together an incredibly simplified version of this.

[robertybob]

I always thought there was a huge amount of lag when I played SMB (!) Looks like I was right lol

[mikeveli20]

I’m getting some lag as well, but no way to measure exactly how much. When I first hooked it up it was really bad. I’m talking it was probably half a second bad (SMW on SNES). I then realized my TV was set to movie mode so I switched it to game and there was a huge improvement. However, still some noticeable lag. I had read somewhere that turning off threaded video and turning on hard gpu sync in the retroarch settings should help and it seems to although that could just be a placebo effect. I still notice a slight lag but it’s a lot better than it was.

[MattRigg]

Disabling threaded video was one of the first things I tried, but it didn’t make a difference. AFAIk, GPU hard sync isn’t actually used on the Pi so I don’t think that setting actually does anything.

[mikeveli20]

Probably placebo effect like I was saying. Definitely some still some lag though. I’m using an official snes controller connected through a 4-play bliss box. It seems fine in the menus but in game it’s much more noticeable. I tried the controller on my actual snes right after and could notice a difference in responsiveness so that rules out the controller on my end. Definitely seems to be a retroarch thing since it added that extra 7 frame delay in your tests.

[Anonymous]

What’s your GPU mem split like? I was having pretty similar input lag. Upped the GPU’s memory to 256 MB and it seems to have remedied the issue.

Setup (for reference):
Raspberry Pi 2 running Retropie 3.4 from sd image
Class 10 64GB Samsung Evo SD Card
OC’d to Pi2 settings from raspi-config script
256 MB GPU Memory Split
Using Playstation 3 controllers via bluetooth (set up via the retropie-setup script)
Tested on psx, nes and snes libretro emulators (all pertinent settings at their defaults)

[MattRigg]

Tried a couple of different men splits (256/768 & 512/512) but it didn’t make a difference. I’ve actually given up for the moment…I’m keeping my eye out for an old CRT TV that I can hack a Pi into. At least I know this will remove 2 frames of lag, then I can start messing around with the settings again and see if I can reduce the lag some more.

There was another member here who was also experimenting with different settings etc to try reduce the lag, but I think he gave up on it too. He was using a RealTime kernel version of Raspbian. I tried this and as far as I can remember, it shaved off one more frame. The downside is that at the moment, overclocking isn’t recommended on the RT kernel image; the SPI isn’t synced properly so overclocking the Pi also overclocks the SPI (which could be bad news if you’ve got anything (i.e., the ControlBlock) hooked up to the GPIO).

I think I’ve just become overly-sensitive to lag in my old age (!). The last time I messed around with emulation was maybe 7 or 8 years ago when I had an Xbox1 hooked up to a CRT. Played loads of NES/SNES games on that thing with my mates and never really noticed the lag. Since I started messing with all of this I’ve tried emulators on my Mac, a Windows machine, and even dug out my old PSP, and they all seem to have some sort of lag that, to me, is very noticeable.
I dunno…if I make any more progress I’ll post back here, but I’ve got more important things to sort out first (moving house, for a start).

[jeffdamann]

You dont have to hack you pi into a crt, at least not a model 2, there is a 3.5 mm jack specifically for it.

[MattRigg]

Right, I know I don’t HAVE to (4-pole 3.5mm jack and all)…I want to ;-)

The idea is to have a CRT with a built-in Pi, with the specific purpose of playing retro games. Depending on time/effort it’ll also have a custom SNES-themed paint job.

But like I said, that’s a project for later on.

[labelwhore]

[quote=113218]
that magnificent bastard Ben Heck[/quote]

Isn’t he though? lol

[malacai]

Hi, have you tested a highs-speed hdmi cable?. That made the lag go away for me.

/mallorz

[iesposta]

I never experienced noticeable input lag until yesterday.
PSX “Kiss Pinball” is unplayable.

I’m at the start of running a new RetroPie v3.5 with a new Class 10 card, normal Pi2 overclock, 256MB GPU split. I know about LCD Game mode, all TV options off.

The high-speed HDMI is something I can try. And maybe a different PS1 emulator?
Devil’s Crush pinball on PCE is playable, even through Framemeister XRGB-Mini… so I’m interested in this thread and other users experiences.

[MattRigg]

Got some spare cash this month so I think I’m going to treat myself and replace all my HDMI cables with some nice QED ones. And yes, I know buying expensive HDMI cables is pointless (digital signal and all), but I’ve got other QED cables in the house and they’re great quality, so screw it…

;-)

If that doesn’t fix the lag I’ve spotted a cheap 21″ CRT on eBay. It’s just a case of seeing if the seller can test a 60Hz/NTSC signal on it.

[nosedeath]

Would switching over to the 4-pole 3.5mm jack from HDMI solve the lag problem?
My TV doesn’t have the option to switch to game mode movie mode. So I too am having a bit of lag when playing NES games…amongst others.

[brunnis]

Just thought I’d add some observations here as well. I notice input lag in RetroPie as well. It’s not a big issue when I use it on a computer monitor, but it is an issue for some types of games when I use it on my Samsung plasma.

I used a very crude method of getting an idea of the input lag. I only had a 30 fps camera available and I used that to film while I performed quick taps on the controller and mouse I used for testing. I’ve taken the liberty of multiplying the number of frames I counted in my recorded material by two, since that better corresponds to the actual number of frames rendered by the source (since it runs at 60 FPS).

The PCs were tested at the Windows desktop, recording the response from the built-in game controller configuration program and from double-clicking to select text in Notepad. [Granted, that’s a bit apples and oranges, so I’ve added some actual RetroArch measurements in an edit further down.]

[b]Hardware & software[/b]

– Raspberry Pi 3 with RetroPie 3.6 and Super Mario World 2: Yoshi’s Island
– Core i7-6700K with Windows 10
– Core i5-5300U with Windows 7
– Samsung plasma TV
– HP Z24i desktop monitor (24″, 1920×1200, IPS)

[b]Results[/b]

RetroPie + Samsung plasma TV: [b]12 frames (200 ms)[/b]

RetroPie + HP Z24i: [b]8 frames (133 ms)[/b]

Windows 10 + HP Z24i: [b]4 frames (67 ms)[/b]

Windows 7 + HP Z24i: [b]2 frames (33 ms)[/b]

I know of one test that has measured the HP monitor’s input lag and found it to be almost non-existent (less than 1 ms). That would put the plasma at around 60-70 ms, which sounds plausible. I tested many times and these results were quite consistent.

So, RetroPie on the HP monitor responds approximately 100 ms slower than the Windows 7 laptop using the same HP monitor. That’s a very significant difference, but the Windows 7 laptop also wasn’t running an emulator.

I love RetroPie, but this issue (which, granted, may have nothing to do with RetroPie itself) kind of kills it for me. A lot of the games I play/want to play on it are fast paced and rely on exact timing to succeed. And I have definitely noticed that they’re harder because of this.

Is there any work being done on attempting to profile this and come up with a solution?

[b]EDIT:[/b]

Did some more testing with the Windows 7 machine, using RetroArch and Yoshi’s Island:

[b]8 frames (133 ms)[/b] with Snes9x Next and video_hard_sync = false
[b]6 frames (100 ms)[/b] with Snes9x Next and video_hard_sync = true
[b]4-6 frames (67-100 ms)[/b] with bsnes (balanced) and video_hard_sync = true

video_hard_sync did not seem to have any effect on RetroPie, but it did seem to shave off a couple of frames in the Windows case.

What’s interesting here is that I could not come close to reproduce the input reponse from the Windows desktop (2 frames). Input response time (with video_hard_sync disabled) was actually the same as using RetroPie. Does the emulator really need that much time to output to the screen?

[b]EDIT2:[/b]

I just tested the input lag when typing at the command line in RetroPie. A typed character shows up in the next recorded frame, which means that input lag is 33 ms at the most.

So, the Raspberry Pi and the PCs have similar low latency input when just reacting on USB input (such as writing on a keyboard). All devices also seem similarly slow to react on input when running the SNES emulator, although video_hard_sync = true seems to help the PCs slightly.

[dankcushions]

I said it in the other thread but poeple really should experiment with video_driver = “dispmanx” in /opt/retropie/configs/all/retroarch.cfg – it’s a ‘bare metal’ driver which may improve latency, but no one has any documented results yet :/

[brunnis]

Funny you should mention it… That’s just what I was planning on doing tonight when I get home from work. :) I will also be using a Canon EOS 70D which is capable of 60 FPS recording, so results should be a bit more accurate.

I’ve read about dispmanx previously, but for some reason I forgot to test it yesterday.

EDIT: Might have to postpone testing another day or so due to family stuff coming inbetween, but I will do the test as soon as possible.

[brunnis]

Okay, the results are in! Tested on my Samsung plasma, since the much better pixel response time makes it easier to spot when a change is happening on the screen. Tested with Yoshi’s Island again and filmed in 60 FPS with a Canon EOS 70D.

[b]gl driver:[/b] 12 frames

[b]dispmanx:[/b] 11 frames

[b]dispmanx + video_hard_sync = true:[/b] 11 frames

I’d say the dispmanx driver was rather consistently 1 frame faster, but it’s still close enough that I wouldn’t bet my life on there being any real difference.

Disappointing results, of course. I wonder what I should test next…

[petrockblog]

video_hard_sync is not used on the rpi

[dankcushions]

there’s some tips here: https://www.reddit.com/r/emulation/comments/41okgr/can_someone_help_me_reduce_input_lag_for_retroarch/ (user libretro should know what they’re talking about!)

it’s also worth experimenting with the input drivers. i think it defaults to udev, but linuxraw might be faster? try the others also.

there is also a new input polling option in settings > input called “poll type behavior” that may help when set to “late” vs “early” or “normal”.

it’s a lot of experimentation but i’d love a sort of comprehensive list of what does/doesn’t help :) would make a good wiki page…

[brunnis]

[quote=119865]video_hard_sync is not used on the rpi[/quote]
Kind of thought so.

By the way, did one additional test:

[b]gl + vsync = false:[/b] 9 frames

Since my plasma seems to have 4 frames input lag (although that’s not confirmed), that would lead to 5 frames latency (or approximately 80 ms) for RetroPie. However, playing without vsync is curiously stuttery on this system.

[quote=119874]there’s some tips here: https://www.reddit.com/r/emulation/comments/41okgr/can_someone_help_me_reduce_input_lag_for_retroarch/ (user libretro should know what they’re talking about!)[/quote]
Yep, I found that as well! Some interesting stuff there.

[quote=119874]it’s also worth experimenting with the input drivers. i think it defaults to udev, but linuxraw might be faster? try the others also.

there is also a new input polling option in settings > input called “poll type behavior” that may help when set to “late” vs “early” or “normal”.

it’s a lot of experimentation but i’d love a sort of comprehensive list of what does/doesn’t help would make a good wiki page…[/quote]
Yep, I’ll have a look at those options as well. I’ll hopefully have time for it this weekend.

[brunnis]

Okay guys, I’ve done a lot of testing since I last wrote. I’ve focused on performing a slightly more in-depth comparison of RetroPie on the Raspberry Pi 3 compared to running RetroArch on the PC, to sort of compare to the best case scenario.

First off, the hardware specs:

[b]Windows PC:[/b]

Core i7-6700K (Skylake)
Radeon R9 390 8GB
Windows 10 64-bit

[b]Linux PC:[/b]

Dell Latitude E5450
Core i5-5300U (Broadwell)
Integrated HD Graphics 5500
Ubuntu 15.10 64-bit

[b]Monitor (used for all tests):[/b] HP Z24i LCD monitor with 1920×1200 resolution. This monitor supposedly has almost no input lag (~1 ms), but I’ve only seen one test and I haven’t been able to verify this myself.

[b]Gamepad (used for all tests):[/b] CIRKA USB SNES replica

I tested input lag in NES and SNES emulators and used the following two games:
[ul]
[li]Mega Man 2[/li]
[li]Super Mario World 2: Yoshi’s Island[/li]
[/ul]
[b]Test methodology:[/b]

I filmed the monitor and gamepad with a Canon EOS 70D in 1280×720 mode at 60 FPS. I filmed while jumping repeatedly (approximately 30 times for each test) and then analyzed the film clips frame by frame to get the average input lag.

[b]Results:[/b]

[b]Raspberry Pi 3 + RetroPie 3.6[/b]

FCEUmm: 7 frames
Nestopia: 6 frames
snes9x-next: 8 frames

[b]Comments:[/b] Nestopia was pretty consistently 1 frame quicker than FCEUmm.

[b]Windows 10 + RetroArch 1.3.2[/b]

video_hard_sync off:

Nestopia: 7 (often 8) frames
snes9x-next: 9 (often 10) frames

video_hard_sync on:

Nestopia: 4 frames
snes9x-next: 6 (often 7) frames
bsnes-mercury-balanced: 6 (often 5) frames

[b]Comments:[/b] Xbox Game DVR feature was disabled in Windows’ Xbox application. Having this feature enabled has been reported to add input lag, but I didn’t really investigate it.

[b]Ubuntu 15.10 + RetroArch 1.3.3 in KMS mode[/b]

Nestopia: 5 frames
bsnes-mercury-balanced: 7 frames

[b]Comments:[/b] video_hard_sync was left off. Enabling it had no effect on performance.

[b]Conclusions:[/b] There are a few conclusions we can draw from these tests. First of all, Nestopia was pretty consistently 1 frame quicker than FCEUmm. SNES emulation seems to be approximately 2 frames slower than NES emulation with Nestopia (at least for the tested games). However, testing on Windows suggests that bsnes-mercury-balanced is quicker than snes9x-next. Where snes9x-next is around 2-3 frames slower than Nestopia, bsnes-mercury-balanced is around 1-2 frames slower. Unfortunately bsnes-mercury is not available on RetroPie (and probably wouldn’t run very well due to its higher requirements).

Regarding platform differences: RetroPie is 1-2 frames faster than Windows 10 without video_hard_sync enabled. Once video_hard_sync is enabled, Windows 10 shaves off at least 3 frames of input lag for both NES and SNES emulation, providing the quickest response of all three tested platforms. The biggest surprise is perhaps that running RetroArch in Linux under KMS still doesn’t beat Windows in terms of input lag.

So, to summarize, the final standings are:

1. RetroArch under Windows 10: 4-6 frames (67-100 ms) of input lag
2. RetroArch under Linux KMS: 5-7 frames (83-117 ms) of input lag
3. RetroPie: 6-8 frames (100-133 ms) of input lag

Although Windows is the quickest, I still wouldn’t call it lightning fast, especially not in the SNES case. Adding a couple of frames for the average TV and you’re already at 133 ms input lag. That may be perfectly fine for modern shooters, but it’s not ideal for super-fast platformers. My Samsung plasma TV appears to have around 4 frames of input lag, which combined with RetroPie results in a total of 200 ms for SNES emulation. That is definitely noticeable and makes, for example, Super Mario World a lot harder than it used to be.

One interesting development that may change things slightly for the Raspberry Pi is the ongoing development of a fully open source OpenGL graphics stack. Maybe someone more knowledgeable than me can chime in on that and shed some light on any possible ramifications? Given the fact that a PC running Linux under KMS can’t shave off more than 1 frame of input lag compared to the current version of RetroPie, I’m not overly optimistic.

[b]Disclaimer:[/b]

– There’s of course some uncertainty in the measurements due to recording at just 60 FPS. However, with around 30 attempts for each test, a pretty clear trend could be seen.
– It would have been interesting to test with more NES and SNES games, but I didn’t have time for that.
– I can’t guarantee that the HP Z24i doesn’t add some measurable latency.
– Different display hardware (AMD, Intel, Nvidia) could very well affect the outcome.

[dankcushions]

interesting about the different NES cores having slightly different latency. i will make nestopia my default, now.

i also wonder if raspian can be run in KMS mode? if so, perhaps retropie could, in the pre-built images?

again i think there’s further testing worth doing regarding vsync, input drivers, display drivers, etc.

[brunnis]

I agree that there’s further tests to be done, but I’m not sure I can spend much more time on this. It was sort of disheartening to learn that not even a powerful PC running RetroArch under KMS can provide any meaningful difference in input lag.

I will probably perform some additional testing on Windows 10, since that’s slightly less cumbersome for me to do. Any interesting findings will then be carried over to my RetroPie setup for testing (if they apply).

Since general interest here seems low, please see the Libretro forums thread for further discussion on the matter: http://libretro.com/forums/showthread.php?t=5428

[starblank]

A thing is resting in the bottom of all this: the reality is that we’re running an emulator. Probably the original snes hardware has a tiny input lag too (it would be nice to measure that). When running snes9x on retropie we have the bluethooth or usb lag + retroarch core lag + original emulated hardware lag? + framebuffer lag + hdmi output lag + tv screen lag, resulting in this…

By the way, the test you drove are simply AWESOME….

[Author]

Posts