Input Lag: Vergleich zwischen Recalbox und SNES Classic Mini

[Substring]

@marcdk your very first formula is right, but you already have a wrong result ...
If 480 frames take 1s, then 171 represents 171*480/1000 = 82.08 frames ... And you said 84 frames. That's already a 2.5% error right from the start.

But the funniest is that you record at 240 fps and finally decide that it's 480fps because ... Because final cut told you. You don't even know. So maybe the lag is just half of what you said : 171*240/1000=41.04 frames

But these frames are your phone's frames. How many snes frames does that mean ? But hey, is your game is running at 60 or 50Hz ? You're not saying.

So at 60Hz, 171ms means 171*60/1000, so 10.26 fps, which turns to 11fps ... For 50Hz, that's 8.55fps, so 9.
The real snes seems to have 3.6fps input lag, we're 3 times bigger.

When is the button really active when you're recording ? We don't know. Why not just record the frame value on RA at the same time ? You'd have some figures to get i deep

And your screen adds 1.5 frame of input lag ...

How often have you made the experiment to determine the statistic parameters regarding the error measurement ?

How can i trust you when you say that wireless pads have almost no input lag ?

This is not serious at all, despite the effort you put in it. I feel like you're tricking people who have no background knowledge regarding what measuting all this means.

[MarcDK]

@substring said in Input Lag: Vergleich zwischen Recalbox und SNES Classic Mini:

But the funniest is that you record at 240 fps and finally decide that it's 480fps because ... Because final cut told you. You don't even know. So maybe the lag is just half of what you said : 171*240/1000=41.04 frames

"Because final cut told you". Wrong. I filmed a clock to verify my assumtion. That's how I know that 480 frames in Final Cut are on second. It does not matter if it runs with 60 or 50hz if you know how long a seconds is since I did not count frames of the game but the frames in the video to get the ms. I know that many other ppl tell you the frame delay of the game but this is not comparable over all different systems.

As I wrote in the article I filmed the joypad from the side to see if the button was pressed down. With 240 real frames this is accurate enough if you make many test runs. I compared wireless with wired pads in the results table. So I know how much the delay is. I did this is in the recalbox menu which is a very low input lag btw.

As I told you: I don't claim to have accurate results. But I the tendency that a SNES Mini, Wii U and Raspberry Pi with Recalbox have different and reproducable types of input lag which can be brought in an order from "low" (SNES Mini) to "high" (Recalbox on RPI3) is verified. My TV (KS7090, According to NEOGaf one of the best gaming tvs) has a very low input lag with 21ms (see article). My guess is that many other people will experience a much higher input lag with their TVs.

So, I really believe that this test setup show the difference between many different solutions to play emulated games. And show at least a comparable value between the systems. This will vary between different TVs of course. But I used the same TV with the same HDMI Input in GameMode,.

[Substring]

@marcdk A TV is not a good idea to measure input lag as it's much slower than a gamer monitor.

240fps or 480fps is afterall not important, because we just want to measure the time elapsed. Your twice more precise at 480fps of course. I still say that you have no idea when the button was pressed, and its a source of error. That's why retroarch had a great idea to light a LED when the contact is done. That way, you know when the button is pressed.

Having the frames from RA is also something interesting because you'd get the frame at which the LED turned on. At this point, on a fast monitor that reaches 2ms, you know your statistical error when you press the button is of 1 frame maximum. Mario will jump on a precise frame. If it's 4 frames later, you can be sure that it's not more than 5 frames. That's a 25% error. Which you can probably reduce by repeating the experiment many times. that's how you should have proceeded.

Now I also remember that the tests on RA were made using KMS, which we don't have (yet) on the Pi. The pi does have a kms version of the GPU access, and it's said to be (much ?) faster. But retroarch is also compiled with dispmanx renderer, which avoids using SDL2 and is said to be "faster" (rumor says it's 1 frame faster, i have no proof of that).

One other test would be to simply measure the "real" input lag of the OS itself bu running evtest. And here I expect you find differences between USB and BT pads. If not, I'll remind any user who complains that BT lags that you proved it doesn't

Final word : the pi is not a wuick machine made for real time processing. But lakka patched their kernel as a real time system, results for them could be interesting, and I'd say their input lag is better than Recalbox.

Your tests do lack your own criticism where you should first have described what composes the lag in itself, where are measure errors, how you'd evaluate them. You can't just say "Guyz, I tell you, Recalbox Snes9x has a 117ms input lag whatever you do. You're all screwed. And that's why i miss all my jumps in Super Mario".

[joinski]

@Substring

It is not about perfect measurements.
It is about comparison.
In comparison (within the same conditions), SNES emulation on a Pi3 with Recalbox has more input lag, than SNES Classic Mini (Canoe).
RetroArch on Pi3 with certain settings can reach the same low input lag level as SNES Classic Mini (see the link i posted above).

[Substring]

@joinski said in Input Lag: Vergleich zwischen Recalbox und SNES Classic Mini:

It is not about perfect measurements.

That's the whole point of it ! How unperfect it is ! What is the error percentage in all that ? at 10 frames lag input, 1 frame is a 10% error. At 4 fps input lag, 1 frame is 25% of error. Si yes, it is unperfect, but say how much it is. And then the article defintely gives a real proof of seriousness.

[joinski]

@substring said in Input Lag: Vergleich zwischen Recalbox und SNES Classic Mini:

@joinski said in Input Lag: Vergleich zwischen Recalbox und SNES Classic Mini:

It is not about perfect measurements.

That's the whole point of it ! How unperfect it is ! What is the error percentage in all that ? at 10 frames lag input, 1 frame is a 10% error. At 4 fps input lag, 1 frame is 25% of error. Si yes, it is unperfect, but say how much it is. And then the article defintely gives a real proof of seriousness.

No, that is not the whole point of it!
It does not matter how much the error percentage is.

Because, I said it already... it is about comparison.
The point is, that the SNES emulator in Recalbox with default settings has a higher input lag, than it could possibly have, when settings would be optimised.

I just tested with my Pi3 and Recalbox 18.02.09 with following settings:
RetroArch Main Menu (Hotkey + B)

Settings
Driver
Video Driver - dispmanx

Settings
Video
Threaded Video - Off

And i think it feels a bit better (less input lag) than with default settings.
@MarcDK could you test it?

[voljega]

@joinski are you at least comparing snes mini and recalbox with the same kind of pad in both cases ? wireless or not ? because if not and you're using the original gamepad on the snes mini and wireless one in recalbox it doesn't mean anything.

also if you're using internal bt on the pi for your test, it's pretty s**tty

[MarcDK]

The only thing my articles tell the reader is that this devices play Super Mario World with an input lag in ascending order: (from best to worst) on my television (gaming tv with low input lag) with the best possible gamepad setup (wired over wireless if possible)

• SNES Classic Mini
• Wii U Virtual Console
• Recalbox (PocketSNES)
• Recalbox (Snes9x Next)

The SNES Classic Mini has according to my measments by far (!) the lowest input latency. Right now it is not possible to achieve a low input lag with a raspberry pi with the current state of emulation. Many ppl tried but the result is always the same: With the regular emulators you need a powerful pc.

This does not lower the achievement of the Raspberry Pi or Libreto. It's free! But it has trade offs. I believe I am not the only person who felt the input lag right from the start on the raspberry pi (Batocera, Recalbox ,Retropie with and without optimizations). If you play with the SNES Mini in comparision there is no doubt that it responds much faster. Even without my numbers.

[joinski]

@voljega

Ok, you are right. The comparison should have been done with the same gamepad. I do not know how much input lag difference is between the SNES Classic Mini wired gamepad and a wireless Xbox360 or PS3 Controller.

Also i noticed too, that the internal bluetooth of Pi3 is not as good as certain usb bluetooth dongles.

But at least the comparison test of "Brunni" from the RetroArch forum is very enlightening. Did you take a look?
He found out, that with certain settings ("video driver" = dispmanx and "threaded video" = off) you can lower the input lag to a level near to SNES Classic Mini.
@MarcDK
Could you please test Recalbox with your method with the settings i mentioned?

In the libretro-forum i found another interesting thread with a guide to reduce input lag:
https://forums.libretro.com/t/definitive-guide-to-reducing-input-lag-to-the-minimum-possible/3028
Maybe some of the settings mentioned there are also possible to set in Recalbox and will reduce input lag a bit more?

[MarcDK]

@joinski

Since we already have a date later this month (we live in the same city) we can test this if you visit me. My experience with this is: These settings work only with a PC and not a Raspberry Pi. It does either nothing at all or emulation becomes slow.

[Substring]

@marcdk just my own experience : when playing with recalbox on a crt i have some tweakes to make to reach better speed. Removing double buffering is one of them. I'll try to list what kivutar (lakka project leader) told me

[voljega]

@joinski on the pi, internal wifi and bluetooth are conflicting which each others, there was some tweaking on the forum a while ago which really improved input lag for internal bt.

But any way I would really compare to the snes mini with a connected controller for both systems, not a bluetooth one.

Also snes should be connected on lcd tv like the pi, not a crt one

[MarcDK]

In my tests, BT and Wifi were disabled. I extend the article to reflect that.

[Substring]

@marcdk disabled how ? With an overlay or just "not used" ?

[MarcDK]

WiFi not used.BT disabled.

[Substring]

@marcdk better disable both with an overlay

[MarcDK]

do you really believe that this has any impact on input lag?

[Substring]

@marcdk prolly not, but there is the wrong way, and the good way to do this. But for bluetooth pads : disabling the right way wifi does have a massive impact (even menwho.s not a picky input lag communist noticed it)

But still, you've got some leads to slighlty improve the global lag performance. And you couldnbe able to save up to 2 frames i think, maybe even a little more, who knows

[MarcDK]

@substring

Let’s assume that some of this settings would actually improve input lag. Why are this options switched off in the first place? I’ll answer the question myself: because they are trade-offs with slow performance and glitches.

Many ppl tried to improve this on the rpi. I asked that question in this very forum about a year ago. It is not possible to really improve the performance to a level that you "feel" a noticeable difference. You do instantly feel a difference with a very powerful pc or the SNES mini in comparison.

I was always a defender of the raspberry pi and recalbox in general. And yes, it is still awesome to have all this systems for free. But if you really want to play this games and have to option to play on real Hardware for comparison you will quickly notice the problems these solutions have.

[Substring]

@marcdk Dude, I know you can probably guess by yourself that:

• we are not Retroarch pros
• some settings could have been written AFTER recalbox was started
• we can't keep an eye on every Retroarch commit + every libretro core commit + every emulator commit + every buildroot commit
• just regarding dispmanx, I'm the one who added it on 4.1
• we terribly lack time and/or contributors to do this ground work
• and yes, we also aim for the "most compatible" configuration in terms of emulation but also arch (pi, odroids anx both x86 share the same RA configuration file)

We're really open to get feedback from users if they are willing to improve anything. But just read our commit log, just check by yourself : hardly any one does.

Now a little earlier in the conversation you asked

So please tell me how to significantly reduce the input lag on recalbox with a raspberry pi. I will measure it and extend the article right away.

@joinski gave you some leads, so go ahead and try it by yourself, measure it, write blog articles if it's your hobby. We both know it will never reach the latency of a modern computer or a dedicated box. But it can be slightly improved, maybe to a point where you can feel "more comfortable" when playing, without ever reaching what a PC can do. Regarding PC, i also remember that some libretro forum member made some measure and sad a windows PC was around 7 FPS of input lag, linux was 1 FPS above.

The input lag investigation says it all, is very complete regarding tests, the way they did it etc ...

Retropie gives a few tricks, despite i'm sceptical about the video max swap chain, i was told to put it to 2 or even 1 by libretro members.