Joycon Input Delay

[theofficialgman]

I believe the developer is already aware of this but for anyone else that is experiencing this issue, I am here to let you know that you are not alone. The bug is that the longer the amount of time the joycons are connected, the greater input delay becomes apparent. I have seen my own setup get as bad as 3 seconds. If it's worth noting, this is using the combined joycon configuration. Also, for anyone getting the VCRUNTIME140D.dll error, what I did was copy a vcruntime140.dll file into the system32 folder on my computer are rename it VCRUNTIME140D.dll. It just worked after that, it seems really strange but I hope this either gets fixed or that information helps someone else out.

[fossephate]

Yeah, I'm aware of the issue, I just don't have the time to fix it right now with AP exams next week, among other things. Hopefully I'll get around to fixing it sometime soon. Thanks for opening an issue though.

[fossephate]

Oh, also just to note: distance to the Bluetooth receiver definitely seems to affect responsivness/response times; although I'm not sure exactly how much I'll be able to do about that

[theofficialgman]

Alright, just to note, I was within 2 feet of the integrated Bluetooth adapter and I felt it still got increasingly worse. Good luck on your ap exams, I know they can be tough, I took ap chem yesterday and have AP Physics 1 today and AP Calc AB next week.

[My1]

well the D in the DLL dependencies seemingly stands for debug, maybe the program isnt properly optimized since it's a debug build...

[facekapow]

Hey, I just wanted to say that this is a great project! Also 2 things:

• I don't know if anyone else is getting this, but for me, the lag only happens on the right joycon after a few inputs
• Also, I don't have much experience in C++ (I only fiddle with it a little bit, I personally prefer JS), but this sounds like a memory issue (whether it's the driver's fault or vJoy's fault)
• I've also noticed that if you wait a little bit after it starts to lag (maybe a minute or so), it speeds up again. Maybe packets are being backlogged?

[theofficialgman]

I compiled the new version submitted yesterday and still experience the delay issue. I hope there is a way to solve this problem because this driver has a lot of promise

[facekapow]

Something's been changed in the new commits that completely fixed this for me. Using --combine and --auto-center, I've been playing Portal 2 for almost an hour with no input lag. Haven't tried without these 2 options yet, but I'm assuming there'd be no lag without them. Thanks @mfosse 👍

[fossephate]

this should be improved with the latest commit, the charging grip still seems to be having some issues, though

[theofficialgman]

Hmm, I got a chance to test it out and it seems like it might be improved but I feel like it still needs work. The right joycon seems to consistently have more input delay.

[theofficialgman]

The right joycon definitely has input delay while the left joycon feels spot on. The input delay does seem to be consistent though. It can't be a problem with my Bluetooth module because this doesn't happen without using the driver

[theofficialgman]

still experiencing problems with both joycons in the release and debug builds. Edit: actually, the right stick feels extremely responsive (using combined mode) Edit 2: I did some more testing and it seems inconsistent, sometimes the joycons disconnect and sometimes the left joycon is super responsive and the right isn't and vice versa. I think you are getting somewhere though. Just to note, I don't have my switch right now since its battery is getting replaced at Nintendo, so I haven't done any possible joycon updates with the new switch firmware

[fossephate]

It should be better than before but I haven't done any extensive testing.

[hollyhoppet]

Hi!

Just wanted to let you know I've been watching this project pretty closely and was also experiencing unusable input delay. I can't speak for the person that opened this issue, but since your last commit stating input delay was addressed, I haven't had any problems and have been happily playing pc games with my joycons now for about half a week.

I have shoulder problems that make it hard to bring my hands together to play games with normal gamepads for long, so this driver has been hugely helpful for me since the joycons can be used with one's hands held apart. Thanks so much for making it!

[fossephate]

I think it's pretty safe to close the issue, but if anyone is still having problems let me know / reopen it.

[theofficialgman]

I figured you would still receive this Matthew even though the issue is closed. I found the problem. It's my computer, I tried it out on my sisters laptop and everything worked perfectly. For some reason my computer is acting possessed and will always delay the input. I'm trying to narrow down now if its the vjoy or maybe some system files. thanks for all your help. You have done a great job

[theofficialgman]

well now that I say that, now it isn't working so perfectly on my sisters's laptop. Oh well maybe it just isn't for me.

[fossephate]

:/ mysterious, I have some ideas as to what it might still be, hopefully I'll figure it out soon.

[gourryinverse]

Interestingly, I've found this bug to be much more apparent when using the shoulder buttons.

Going to do some protocol profiling work a bit later

[imarceldoe]

Input delay is also still really bad for me.

[theofficialgman]

As of comment 157b108, I have noticed some new occurrences to me. Upon first starting up the driver, with combined, auto centered, and gyro activated, every time, one of the two joycons would disconnect. What I found out was that the gyro was causing it to disconnect and disabling it would fix the problem. Also, I experienced no input lag for about 5 minutes after disabling gyro until seemingly randomly the lag was back. It would then come and go sometimes not appearing again for another 5 minutes, sometimes it would stay for 10 minutes. I just thought I would note that. Keep up the good work.

[hollyhoppet]

So turns out I'm still getting the input lag issues on one of my machines, and as someone who did a lot of mobile programming with a specialty in performance optimization and finally some time on my hands, I was finally able to take a look into it.

I've put a preliminary fix up on a fork (https://github.com/HollyJean/JoyCon-Driver) and so far things seem to be performing better than ever. It's fairly cowboy code and I'd like to make it require a flag for now so I'm not ready to open a PR yet, but will have time hopefully on Sunday evening or Monday to clean up and submit.

(More technical details follow) Looking at your code, the operations that are done are all really just a bunch of simple math, which usually doesn't cause much of a performance impact. After some strategic logging, I had a hunch the bottleneck was updates to vjoy. My guess is because the joycon driver polls so rapidly, vjoy's buffers get overloaded or something? Anyway, I offloaded sending updates to Vjoy onto another thread, per vjoy device, and while an update is being made, any other calls to update are just ignored.

The solution seems to be working pretty dang well but I want more time to test it (hence the desire to make it just an option for now). I was worried there would be occurences of buttons presses or releases not being reported since it's dropping update calls, but that doesn't seem to be the case. If anyone is feeling adventurous feel free to check out my fork and give it a spin and see if you can find problems with it. Note that I did not do a build (don't have the win8 sdk atm) so you'll have to build it yourself.

[fossephate]

@HollyJean Ironically, when testing your fork, there was a lot of input lag; which is why I still think the issue is with the understanding of the joycons && the command structures. I think it may also be a timing issue(which would explain why it sometimes works better than others).

[hollyhoppet]

Sigh welp that's computers for ya :P

[imarceldoe]

@mfosse Do you think this is also why there's frequent disconnects?

[hollyhoppet]

Testing out another fix on my fork for the next couple days, this time related to the way reads are made from the HID device. It seems there may be an issue with using hid_exchange exclusively to get messages from the joycons, as I found that 0x3F messages might possibly be sent by the joycons even without a status message being sent, causing a buffer of messages to build up, one of which are only grabbed each time a status message is being sent.

[imarceldoe]

@HollyJean Any chance I could help test this?

[timmeh87]

Hey guys, I am guilty of reading only the first few posts of this thread before replying but I have noticed the same issue and I can maybe suggest a root cause for the problem.

My hardware is not a real joycon, it is a device I created myself that looks like a joycon to the Nintendo console. A Joycon emulator or "fake-joycon".

When I was using this driver,with the fake joycon, I noticed an input lag problem. At first the lag was a few hundred miliseconds, but it got worse and worse over a period of a few minutes until it was seconds long.

Since I can debug the code on the joycon side of things, I was able to locate the problem fairly quickly. It seems like the joycon-driver is spamming "0x00" subcommands to the joycon. Each time this subcommand is received, the joycon replies with a button report. I think this behavior might be intentional in order to "keep the flow going", as the joycon will not usually send button reports when no buttons are being pressed.

The issue is simply a buffering issue. So many button reports are being sent that they start to back up in various buffers throughout the system. I modified my code so that it does not reply to 0x00 subcommands and the lag was instantly gone.

Using this page online: http://html5gamepad.com/ I was able to view the timer or counter value on the joycon device (NOT the vjoy device) go from incrementing over 100 times per second, to incrementing only up to 60 times per second (this is the regular report rate for a joycon).

EDIT: as a side note, In theory this constant stream of 0x00 subcommands causing the issuing of numerous extraneous button reports might impact the battery life of the joycon, since it is kept in the highest power mode (transmit) for most of the time

[Kyrio]

@timmeh87 Have you looked at @HollyJean's explanation for his fork (scroll up)? He seems to have also noticed that updates were too frequent and created buffering issues. His fork eliminated input lag with my Joy-Cons.

[timmeh87]

Well that is it then, I suggest we pull that code asap or else implement a throttle of some kind to keep the report rate near 60hz

[CTCaer]

Actually, since this is a full fledged driver, the correct way to do it is to stop sending id:x01, subcmd:00 and parse x21 reports.

It should send a id: x01, subcmd:x3 x30 once, so the joycon can start spamming x30 reports.
This way, with a x30 input report parser, the latency should reach around 16ms.
Rephrasing the above, the connection should be one sided. The only thing the driver should send, is id: x10 rumble reports every 120ms. Or every 8 x30 received.

---

There are numerous ways to do it. Best way is a thread with blocking hid reads.
And a second thread for parsing. Lastly, a FIFO queue for the 2 thread communication, would also be a good idea.

Another way is to use a loop with timeout hid_reads and when they are not receiving anything and time out, the parser does keep the same values from the previous packet.

[timmeh87]

^ this guy knows what he is talking about.

I do support the idea of changing the driver to operate correctly, but it might be a lot of work for mfosse to refactor the code and in the short-term I think we should accept a hack fix that does correct the immediate problem

[CTCaer]

Ok, then for now the quick fix is to implement a timer.
And if dt >= 15ms then send a x01 ouput report and parse the x21 report.

Also about my previous comment, a very simple loop is the one I have here

If you also comment out the limiter if statement, it can reach real time parse of 15ms.

My code is for reference though (because the scope of the app is testing). Check my analog stick parser also. I implemented a parser that uses the calibration (factory or user) and applies center and outer radial deadzones. The good thing is that it can be optimized way further, even though it can still parse real time.

[fossephate]

@CTCaer @timmeh87 for now I reduced the poll rate to 60Hz, but this far from perfect and I'll try implementing a better solution when I get back to my apartment (around 5pm eastern)

[theofficialgman]

still experiencing input lag on one of the joycons on dcea71f . It seems vjoy is still being bottlenecked.

[fossephate]

@theofficialgman It's a temporary fix until I have more time

[hollyhoppet]

Just took a look at the commit linked (dcea71f), and yeah that's more or less the fix I did on my fork, so thanks for doing that and anyone who's been using my fork might as well go back to the main project. I ended up needing surgery (it was successful and I'm recovering well!!) so was never able to get around to making a pull request but I'm happy to see at least that stopgap solution in the main project now.

Also imo @CTCaer's comments are right on the money for a great final solution to the problem.

[Kyrio]

Glad to hear you're okay!

Edit: Well, I might still need to use your fork. I haven't encountered connectivity issues in 9847582 yet, but I still have important input lag (especially on the left Joy-Con) that is curiously absent with your workaround. I wonder why everyone doesn't experience the same reactivity, is it linked to our Bluetooth adapters?

[BanchouBoo]

In ddf5c7c I still get input lag in the right joycon, but when I first start the program, there is little to none. Using the gyroscope visualizer and the vjoy monitor I noticed the input lag doesn't start until about 2-4 seconds after starting the program.

EDIT: it seems the input lag is only present with both joycons connected (regardless of if I combine them or not), if I connect just the right one it's smooth as butter.

[ZukeG]

@HollyJean's fork is still the superior version. I get the same situation as @TheBoyBoy, where the input lag starts out fine, but then gradually gets worse and worse. The fork is as smooth as butter in comparison. However, the problems with the gyro controls in their fork still stands - whenever gyro controls are on, one of the Joycon disconnects. It's a trade off - input lag with gyro controls vs. no input lag without gyro controls.

[fossephate]

@ZukeG is it still only apparent when both joycons are connected?

[ZukeG]

@mfosse Even when they aren't connected, it still has input lag. When both are active, regardless whether or not they're connected, it has input lag.

[Wadl3r]

HI!

I too experience delays when using your driver. Without it, there is no lag whatsoever, but unfortunatly I need analog input to play my games. Is there any fix on the way?

I've also seen that there is close to no delay in the first few seconds after your driver initialized.

[fossephate]

@Uglynator it's a known bug, and it's sometimes hard to reproduce, what Bluetooth adapter are you using and what version of Windows are you running?

[Wadl3r]

I'm running Windows 10 Pro 64 Bit, with an old Belkin bluetooth USB dongle. I think it's bluetooth 1.1. But the Joy Cons work lagless without using your driver, so I don't really think that's the issue here?

[Kyrio]

For what it's worth, I'm experiencing the issue with a Windows 10 64-bit laptop and Bluetooth 4.2 (integrated Intel Bluetooth adapter).

[fossephate]

Does it still lag if only one joycon is connected?

[Wadl3r]

Yes.

[Kyrio]

@mfosse So... that's odd. I've had these problems since I started using this driver, but today I've been testing the latest version and encountered no input lag issues or disconnects in combined mode. Besides, after closing the driver window, the Joy-Cons weren't disconnected either: both had their first light still on, and I could go back to the regular "Wireless Gamepad" driver by pressing the sync button once, then any button on each Joy-Con. I'm adding this because I often had to re-pair them after interrupting the driver with earlier versions.

I'm not sure which commit triggered this but in any case, great work. I'll test it some more tomorrow.

[fossephate]

@Kyrio the inconsistency of the bug is why it's been so hard to fix

[shadowninja108]

So I have seemed to notice some things in my own research. At least on my set of joy-cons, the right joy-con seems laggy while the left one is very responsive. I'm pretty sure the polling of the joy-cons is synchronous, so the program must wait for the right joy-con before it updates vJoy. My hackintosh doesn't even recognize my right joy-con as a HID device, but it works with lag in Windows. I think this might be a hardware issue.

[programista91]

I also have a huge lag with this fork.
I tried the fork from @HollyJean and this one works without delay, but after a moment one joycon always disconnects. Anyone help?

[LAPIII]

Is the lag issue fixed? What does everybody use now, perhaps a fork?

@timmeh87 I'd love to see your "fake-joycon" that you made. Please upload pictures.

@TheBoyBoy What is the gyroscope visualizer?

[hollyhoppet]

@LAPIII your timing couldn't be more perfect lol. I literally just released the first version of a project that does this, but written in python (I tried working on this one but couldn't stand working in C++ lol). You can check it out here https://gitlab.com/hoppet/joyconvey/blob/master/README.md

@fossephate if you'd prefer me not to advertise my project here please feel free to delete this comment, or ask me to if you can't.