Yuzu: High input lag/latency

Created on 20 Jun 2020  路  22Comments  路  Source: yuzu-emu/yuzu

Input latency in yuzu is very high for me. Both with keyboard or with a controller, there is a very noticeable delay. This doesn't just apply to keypresses, analog sticks and the touch feature is affected as well. The video I am attaching is in real time, the delay is clearly visible. I'll also include a generic log. The issue seems persistent regardless of version or game playing. Testing over on Ryujinx input latency is much lower

Video:
ezgif-4-40ca74412c5b

Log:
yuzu_log.txt

Most helpful comment

@resadent This has nothing to do with fullscreen. On linux there isn't even a concept of "exclusive fullscreen"

All 22 comments

I've noticed the same issue. In both yuzu and yuzu-cmd, there's is a noticeable delay between my input to the gamepad and the response in yuzu. The issue was not observed in other applications, including of course the HTML5 Gamepad Tester as well as Citra.

Video, Gamepad Tester, yuzu_log.txt

My specs are:
Manjaro 20.0.3, Linux 5.7.2-6-tkg-pds
AMD Ryzen 7 2700X
GTX 980 Ti on 440.82
16GB 3200CL16 @ 3400 MHz
Controller is, in this case, a HORI NSW-108, but identical latency also observed on a HORI NSW-001, a PowerA 1507843-01, and a Sony DS3 CECHZC2U over USB.

Given that gamepad support in Linux is baked into the kernel, this is likely not a driver issue.

Our polling rate is probably wrong, causing this delay to happen.

(https://github.com/yuzu-emu/yuzu/blob/master/src/core/hle/service/hid/hid.cpp#L42)

I guess this issue has to do with input lag too: https://github.com/yuzu-emu/yuzu/issues/4053. Hope yuzu gains exclusive fullscreen too in the future :).

@resadent This has nothing to do with fullscreen. On linux there isn't even a concept of "exclusive fullscreen"

Just wanted to mention I'm running Yuzu 297, Win10, 3600x and GTX 1070 and experiencing the same very long input lag in Super Mario Odyessey. What is weird is that jump button doesn't seem to be that laggy, but moving Mario with the analog stick is incredibly laggy and unresponsive. I am using a wired Xbox One controller, and I have no issues with other games or emulators re: input lag.

So I've been playing with vkBasalt on Linux (basically ReShade for Vulkan, it even supports the same shaders to a degree). I noticed some of the shaders such as qUINT_mxao render ahead of the on screen image. Since I'm sure I'm not explaining this properly, here's a video. Notice how the mountains in the background, the black shadow from the shader is moving ahead of the mountains. I later tested that the controller latency is no different on the BotW main menu even when vkBasalt is enabled, so there is no extra latency induced by vkBasalt. My guess is this is a renderer issue, not input.

Having Cemu and Yuzu open at the same time running Mario Kart 8, when I press a button it's easy to notice that Cemu reacts faster in the menus when looking side by side. I've been noticing all games in Yuzu are a bit too high on the input latency.

I just did a quick and dirty test: ran New Super Mario Bros U in sequence on Cemu, Ryujinx and Yuzu, all fullscreen without vsync, and measured how long it took from pressing the jump button until the first frame of Mario reacting. I filmed both the controller and the display at once in slow motion, 240fps, then counted the frames and divided by 4. Did 3 or 4 jumps each time.

It's certainly not the best method, but this is what I got:

Cemu: 2-3 ingame frames of delay. Unnoticeable when playing.
Ryujinx: 5-6 frames.
Yuzu: 7-8 frames. The delay is visually noticeable even without slow motion.

Haven't really tested any other games than Mario Odyssey but it's very noticeable when turning with Mario. Using Windows 10 2004 with a Geforce GTX 1060. I don't have any issues in other emulators.

Im having this exact issue, both USB keyboard and DS4 controller. I have googled for hours and tried every trick under the sun to fix it. I even did a clean windows install. Full up to date drivers. Latest versions of everything. Nothing will fix it. This isssue is only present in Yuzu, not any other application

My "latency" was caused by me having configured my controller wrong. I had configured each axis individually instead of clicking "Set Analog Stick" which made the analog stick digital and the controls felt really wonky. It's all good now!

I did some testing. I changed SDL and HID poller frequency here are the results
sdl 100hz, hid 66hz = 1-4
sdl 200hz, hid 66hz = 1-3
sdl 100hz, hid 200hz = 0-2
sdl 200hz, hid 200hz = 0-2
sdl 500hz, hid 500hz = 0-2
sdl 100hz, hid 66hz, no speed limit 325fps on cave story+ = no skipped frames

Something else in the core is delaying the input. The input itself has no delay.

Hey yall,
I've made a PR which might fix this issue. It should be in the next early-access build.
It would be great if you could test if it changes anything.
If you don't have access to ea, you can also PM on Discord(Tobi#6629) and I'll help you tets the changes.

Wow, great work. The difference is immediately noticeable on NSMBU, the game feels perfectly responsive now.

Ran again the same test I mentioned before, filming button presses and NSMBU jumps at 240fps, counting frames and dividing by 4, rounding to the nearest integer. Cemu and Ryujinx had about the same results as before. But Yuzu went down from 7-8 frames to consistently 5.

Out of curiosity, to test overal responsiveness, I also tried Super Mario World on BSNES in Retroarch, and it had between 1 and 2 frames of latency.

Here are my results in frames of delay at 240fps, before conversion and rounding. Six jumps each.

Cemu 1.21.1b (OpenGL, Fullscreen, VSync off)
7
12
10
9
12
9

Ryujinx 1.0.5327 (Fullscreen, VSync off)
18
22
22
21
18
19

Yuzu EA 948 (OpenGL, Fullscreen, VSync off)
21
19
19
21
21
21

BSNES (Vulkan, Fullscreen, VSync/G-Sync on, Run Ahead off)
7
5
7
6
7
6

Haven't done any major testing but couldn't feel any immediate difference in Mario Odyseey.

I did the ACNH keyboard test again and it does feel a lot more responsive, here's a comparison

Before:
old input

After:
new input

Closing this since the input delay seems to be fixed by #4643 for most users

I would like to suggest leaving this issue open and asking people to contribute more data, preferably comparing different games on Yuzu and on the real system. Although many users may not notice the remaining input lag, it is still considerably high. Other emulators, like Cemu, show it's possible to halve the present values here, if they are related to the program. It would be a matter of emulation accuracy in this case, since 60fps action games that rely on reflexes are meant to be played with the lowest latency possible, just as much as they are meant to be played with sound and without shader compiling stutters, issues Yuzu dealt with before.

And even if the current level of latency comes mostly from the Switch games themselves, having lower input lag than the original system (if at all possible, of course) would be a nice improvement, like being able to play with higher resolution and frame rate.

At this point is not an issue but a feature to have lower input lag. A different input engine and possibly a input rewrite would be needed to lower the input delay

I'd say it's an issue if the emulator has considerably higher latency than the real system, and a feature if it's close or the same already.

Also, I've seen comments about how exclusive fullscreen could reduce input lag, and afaik it's not implemented yet, is that right?

Was this page helpful?
0 / 5 - 0 ratings