His testing setup is only for video latency.
I assume anyone could test audio latency just by putting a microphone and a gamepad next to their speaker and then recording a button press. Take that audio file into audacity or whatever and then look at the timing difference between the button click and the sound effect firing.
It seems like Mednafen Saturn has some input lag problems as well.
I have a question to you brunnis, I have actually bought myself a J4205 (in an asrock beebox) as a dedicated retro arch box but I cannot run games reasonably without having threaded video enabled. Is that a limitation of the very small form factor of the beebox thingy or am I simply doing something wrong? I am using Ubuntu 16.10. and run Retroarch 1.6.1 in KMS Mode, video_swap_chain is set to 2 and frame delay to 8. Are you using threaded video mode yourself and were your input lags tests run with it enabled? If so, what latency change does the threaded mode cause - Thanks for your help!
Unfortunately, I have not tested the difference between having threaded video disabled/enabled. I always have it disabled. I only run NES and SNES emulation currently and without using shaders and using a 1080p display, I can use max_swapchain_images=2 and a frame delay of ~6. Using a higher resolution display, such as a 4K TV, will increase the system load noticeably, although I haven’t quantified it. If you’re using a 4K screen, I would suggest actually running RetroArch in 1920x1080 instead.
There’s one more thing: A while back I updated my Ubuntu 16.10 installation. This updated the Linux kernel (don’t remember the version) and Intel GPU driver. After this, I noticed significantly worse GPU performance and I had to downgrade to restore performance. So, if everything else fails, try a completely fresh Ubuntu 16.10 installation with no updates.
Thanks for your answer! I now found out that I simply had to set frame delay down to 4 and I was able to not use video_threading! 
Frame delay should be the last thing you tweak. Get your other settings the way you want, and then dial in the amount of frame delay that your system can handle. This frame delay amount will vary for every emulator, in my experience.
In previous tests you found that shaders can introduce significant input lag. In your more recent tests you found it produced no input lag. What do you think changed in that time to account for the difference? Thanks :).
This was actually the first time I’ve tested how shaders affect input lag. Previous testing was performed by hunterk and given the pretty long time that passed between his tests and mine and the probably significant differences in hardware and software setup, it’s pretty much impossible to say.
Someone will probably have to reproduce this behavior again and then we can start comparing test setups to try to pinpoint the cause.
Hi,
Is there a final answer on Input Lag GL vs Vulkan on Windows 10 ? Is it hardware dependant (ATI vs Nvidia) ?
Thank you
Bubs
Nope, no final answer yet. New tests should be done on both AMD and Nvidia hardware with the latest drivers. Unfortunately, I now have very little time for such tests and I no longer have any (modern/supported) AMD GPUs.
Brunnis for 240p output on rpi3, do you recommend dispmanx and some frame delay to get input lag as low as possible? What about USB polling rate, could that effect things as well?
I haven’t personally used 240p output, but the same setting recommendations should apply, i.e. DispManX for lower input lag. Frame delay will provide an improvement as well, but may not be feasible if you run any kind of demanding workload. Higher USB polling rate will improve the input lag, if you can get it to work reliably (I haven’t tested it myself).
Do you know how to change the usb polling? My friend is trying to do it now. Is it something in Retroarch itself?
FYI this is now controllable with the HW bilinear filtering option (video_smooth). can be removed in original post
I saw it posted somewhere that if you are using hard gpu sync, there’s no reason to touch the frame delay settting. Is that true or is there still a use for frame delay on conjunction with hard gpu sync?
Thanks! I see hunterk made an edit about that.
Those settings are not related to each other. Frame delay will still work the same, whether hard GPU sync is used or not.
[quote=“Bahn_Yuki, post:478, topic:4407, full:true”] Do you know how to change the usb polling? My friend is trying to do it now. Is it something in Retroarch itself?[/quote] No, sorry. I haven’t dabbled with that yet.
@Brunnis: I think I have found a way to cut a frame of input lag with GLES on the Raspberry Pi using the Broadcom graphics stack (dispmanx+GLES). It comes from this idea I had and talk with popcornmix of Pi kernel fame:
I would like you to test this new idea, I have a RetroArch repository with it’s implementation here:
I have also uploaded a test binary (for Pi3) here, in case you don’t go into the building process:
So, Brunnis, can you apply your magical LED & camera equipment and test vs plain dispmanx, etc? Simply use the GL driver: should have the same ammount of lag than the plain dispmanx driver now. Thanks!
That sounds awesome, vanfanel! Unfortunately, I won’t be able to test this right away. I have my Pi loaned out at the moment and I’m also very short on time since I became a father (of two!) a few months ago and also have a lot going on at work. I’m not saying that I won’t test it, just that I might not be able to do it for several weeks… 
Hey Brunnis! Congratulations on the family growth! 
Don’t worry, test it when you can, no hurries.
Thanks!
In the meantime: If you have a phone or other camera with at least 240 FPS recording, you can get some decent results by filming the controller from the side (in front of the screen) while quickly tapping a button. I also found out yesterday that there’s an iPhone app called “Is It Snappy?” that makes it possible to pretty quickly make the frame analysis on the video and calculate the resulting lag directly on the phone.