I have too Logitech F710 and i have saw this issue with Gran Turismo 2 and lr-pcsx-rearmed. During the race, sometimes, the controls are freezing, for example, i can't brake or turn the car. To fix this i have increase the psx cpu speed from 57 to 67 for this game. I didn't notice it with other emulators because i use the controller only with the games that support vibration.

I have saw the same issue with the same game and controller with other gaming distro and is more noticeable there.

With Logitech F310, that is not wireless, i don't have this issue.

update -

i retired the 1600x1200 screen from 2007 (LP2065, which is the same panel as the 2007FP) and switched to my main 1080p monitor i use for the MiSTer - Acer Nitro XF243Y (https://www.rtings.com/monitor/reviews/acer/nitro-xf243y-pbmiiprx).

there wasnt anything wrong with the LP2065, but after doing a swap and test with my gaming monitor, it was apparent the monitor from 2007 doesnt hold up well in 2023. while very sharp and 4:3, the response time seemed sluggish compared to the Acer, almost like the LP2065 was on a slight video delay.

and the overall input lag experience was noticeable. the reported input lag of a LP2065 panel is ~16ms at 60hz

and the XF243Y is ~9ms at 60hz (see rtings review). while thats not too much of a difference in actual input lag, when combined with the almost instant response time of the XF243Y, the LP2065 just "feels" old.

also better colors on the Acer, and its an LED panel so it uses way less power and doesnt get hot. i am happy

@Glorytonothing said in Experiencing input lag on lr-PCSX-ReARMed:

aftermarket 5V 2A power supply

could be the issue. do you get any voltage warnings (lightning bolt symbol) in corner of the screen?

please also supply the complete information requested by @mitu’s link - including verbose log.

@wild-snail please fill out https://retropie.org.uk/forum/topic/3/read-this-first (including verbose log) for further support, thanks.

@scoularis said in What input lag reduction settings are you using on your Pi 4?:

For me if I used swapchain = 2 in conjuction with runahead, even with threaded video still left enabled, I'd get severe hitching in several games that I tried. Alien Soldier and Disney's Aladdin being the two that I tested that made it clear to me that I just had to leave runahead and swapchain at 3 for that core. Video threaded being disabled seems to be fine with those settings though.

Disney's Aladdin is an interesting rom (and nice to play :) ) - there seem to be 4 frames of internal latency in the game [edit: no, there is only 1], so the lowest latency working configuration that I had was to set threaded video on (the default), swapchains at 3 (the default), and use 4 frames of runahead (which I tested in single instance mode/second instance = no)
[Edit: It plays OK with 4 frames removed, but when I stepped through a frame at a time I can see that removes 3 frames of animation after the button press]

That's with a shader running (I'm trying zfast_crt_standard.glslp - thanks for the suggestion)

I haven't found any situation on a Pi4 where zfast_lcd_standard.glslp allows me to run anything that crt-pi didn't yet.

There is a thread about this.

@marine88 I use the Plugable 4.0 BT dongle, but run it on a short USB extension cable so I can get line of sight. I use this old docking station, but I expect another of good quality should work (if I were you I'd get a powered one so you can at least take power drain out of the equation): link

Basically, get that Plugable dongle as it's amazing and get a decent USB caddy!

@squishykoishi

am not using hires version and in fact locked the screen res for N64 games at 720x576

this can add lag as you’re forcing your tv to do an up scaling operation. see https://github.com/RetroPie/RetroPie-Setup/wiki/Input-Lag#use-hdtvs-native-display-resolution

retropie already runs (most) n64 games at 320x240 and then let’s SDL to a (fast) upscale using the GPU.

the rest of the input lag wiki may help you if there’s still an issue.

weird that gles2n64 etc fix the problem but they don’t have accurate emulation so may have incorrectly quick latency to start with? not sure

@cacotigon
Top time is something like that, Kirby Samurai is a minigame, randomly the screen flashes: !!! and you press a button as fast as you can to respond. So long as you aren't cheating, and you give yourself enough chances, and you're not impaired, if you can't beat your top score; then you have a good personal idea of the input lag.
So you get (input lag)+(legitimate human factor)=(top time)
My best time on a real nintendo was 8,11 average, 13-8,11 = "5,2" the input lag and time measurements, might be per frame, I dont know, 5,2x .06 = 300,120ms { + runahead 1 frame } = 360,180ms. You can divide that result by two because we are experiencing an input and an output lag: ~90ms does that sound about right?

Run-Ahead didn't work as well in kirby-superstar, more framedrops, I forgot what I did to get it up to speed, maybe it was a The second run-ahead, but it kind of seemed contradictory, so I thought it was a fluke but I did get a higher score.

Run-ahead on SMW I thought it felt a lot better when I got it up to speed, v-sync needed to be on or else scrolling looked terrible in one trial. I overclocked and I adjusted the audio latency, and used different cores but I wasn't compiling my test results so I don't know.

I'm back at it again though, now that I've stabilized my overclock. I may just browse the web forums and raspberry pi stuff for a while.

EDIT: Oh yeah! you can read my edit history on my previous posts, I tried to compile as much of it as I could but it is pretty much just as disorganized and I was embarrassed as I can just go on and on as I don't know what I'm doing.
EDIT2: Actually I can't figure out how to read edit history.

@Brunnis Hello Brunnis, I am glad you had a quick look at my results. I have high respect for your work.

I know something must went wrong on my test, as the outcome wasn't consistent and I didn't know the actual delay for input and output devices or even used wrong emulator settings. I expected some sort of delay and just wanted to know how my personal setup works. Currently, there the only way to play on CRT for me is to use that converter.

Quick test of GAMEPAD and CONVERTER

I did a quick test on my USB Fightstick on my PC without RetroPie.

Test 1 does not involve any display. It was just to see how long the LED light on the stick needs to turn on after pressing a button. This is hard to tell, as I can't say for 100% sure when the actual press of button sends a signal. At least the converter, monitor and usb aren't involved here.
Result: 1 or 2 frames of 240 fps, which translates to 0.25 to 0.5 frames at 60 fps (right?).

For Test 2 I used my daily Linux PC with 144 Hz HDMI monitor (without converter). jstest-gtk on Ubuntu was used to visualize a press button on display.
Result: I think 4 frames of 240 fps footage in addition after the LED is lighting up. That translates to 1 frame delay at 60 fps.

At Test 3 I connected same PC to the CRT PC monitor via HDMI to VGA converter. Same jstest-gtk was used as previous test.
Result: 6 or 7 frames at 240 fps footage after the LED is lighting up. Which translates to about 1.5 or 1.75 frames at 60 fps.

Conclusion:

The arcade stick seems to add 1 or 1.5 frame delay on its own, which would mean 16.7ms or 25ms. If Test 2 and 3 are compared, the converter seems to add 1.5 or 1.75 frame delay on its own, which would mean 25ms or 29.2 ms. So, both together are in total adding up approx. about 3 frames or 50 ms latency.

Do you think the autofire/turbo-2 function of arcade stick could send too many key press events, so the emulator or driver gets too busy? Could this have an effect? What do you think about all of this? Does these sound reasonable?

And, should I also just copy the posting to Reddit?

@lilbud yes they are always advertised as 720p "HD ready", the panel size is "implementation detail" ... your experience sounds great.. not every 1366 x 768 panel is made equal.. nor the controller boards.. so I guess you got a good value for your money :)

@mediamogul said in Maybe a solution for NES input lag.:

@lesk said in Maybe a solution for NES input lag.:

Where and how do I enabling that, and what does that do?

The Run-ahead feature gives you the option of removing inherent frames of latency that are built in to every game past the Atari 2600. Each game can have different amount, but as mentioned above, there will always be at least one frame. Removing more frames than what is required can lead to visual and game play anomalies, such as a 'Game Over' screen appearing for as little as one frame when you haven't died. Even when anomalies aren't noticed, the timing of the game's progression is being changed to be more forgiving, making it similar to cheating with a Game Genie code. If you're looking to enable it just for the NES, you can add the following lines to /opt/retropie/configs/nes/retroarch.cfg above the #include line.

run_ahead_enabled = "true" run_ahead_frames = "1" run_ahead_secondary_instance = "true"

Thank you for the information! I'll try this when I get back from work, and only use run_ahead_frames = "1" instead of 2 ^^

I had the same issue with the same controller. I suspected it was the Xpad driver and was correct after updating everything else individually.

I'm not certain it will fix the issue, but here is my working Xpad driver's entire folder.

Working Driver: https://drive.google.com/file/d/1HYT5lnioWIvuF3LuNHe4Wf91DzfLM5-k/view?usp=sharing

These go in /opt/retropie/supplementary/xpad, but everything in there requires Root access to alter.

SSH Method: https://retropie.org.uk/docs/FAQ/#why-cant-i-ssh-as-root-anymore

I hope I was helpful.

@dankcushions
Thanks. Emulation is always funny. I will mess with the nes emulator settings from that guide. I love this project though, such a good use of raspberry pi.

@thelostsoul

The supported tweaks also yield the best results by far. Setting a television to game mode alone feels like the difference between night and day. Setting even all of the possible unsupported tweaks feels more like the difference between night and a bit later that night.

@mediamogul

Excellent, thanks a lot.

@m0riarty Better response might be from the better performance of the emulator tested. MAME4ALL is based on an old mame version is no longer developed, things have improved over time.
If you wish to investigate more, head on over to the docs and you can see all the available arcade emulators on RetroPie - https://retropie.org.uk/docs/Arcade/

@tetragrammaton92

On NES games the music plays way too fast, and on SNES games, there are minor issues with the sound.

I can't speak to the SNES issues, but I believe both lr-fceumm and lr-nestopia need to be aware that a game is PAL before they will play at the correct speed. If I remember correctly, lr-nestopia achieves this by checking the NstDatabase.xml file in your BIOS folder and lr-fceumm checks for "PAL" to be included in the file name. Outside of that, you can also force PAL from the core options in the RetroArch menu as well.