DInput Rumble causes slowdown

[MayImilae]

If you or DarkStalker can bisect it to the revision that causes the issue I'll make sure it's forwarded to the right person!

[DarkStalker]

On 5739 it already has this problem.
idk exactly in which revision it started, but on Stable version this rumble problem really don't happen.

I will search and see if I found the exact version where it starts.

[AnyOldName3]

Make sure to bisect revisions, as it should massively reduce the amount of time testing takes. You can use the Dolphin Bisection Tool to help.

[DarkStalker]

Found it doing my Ikaruga test reported here!

Problem starts on version 5522.

Version 5509 doesn't slowdown the Dolphin while it rumbles.
Also interesting thing is that until this version the Rumble is weaker (easily to notice it on Ikaruga presentation scene).
@5522 it is stronger but also introduces the problem I was reporting on this post.

Sry, but I don't know what is this bisection thing. Can you do it for me?

Anything can be done about this rumble problem with DInput?

Thx all.

[AnyOldName3]

Bisection is where when you have a known working revision and a known broken revision you test the revision in between to half the range you're looking at instead of having to test every build. If you've found the change without it (or without knowing that it had a name) then that's fine. It's something that we recommend quite frequently because lots of users think they have to waste a lot of time checking thousands of builds when in reality ten to fourteen is usually enough.

[DarkStalker]

I used like an Binary Search to found it. :-)


Hope anything could be done about this issue.
Thx for the support.

[JMC47]

Isn't this an issue with certain drivers? I thought we determined in the past this bug was outside of Dolphin?

[ulao]

Ok I did have a chance to poll a few logs. Looks like my assumption was right. Someone had the notion that spamming the FFB engine was a good thing. Not only that but they did so at one frame before the usb polling. That is twice the "wrong" thing to do.

If you look at the screenshot you will see that the usb poll, in this case (and normally the case) is every 8 ms. You will also see the Force FB occurs at the same interval. Also just before the usb poll. 

1) Sending a control or out transfer just before you poll for controller data if not good practice. After would be preferred. 
2) Sending rumble (ffb) data at a rate of 8ms is not going to gain you anything. 

Once you give the GC controller the signal to turn on, process the command, and start up the motor, you are looking at somewhere around 120ms (slow in other cases like PC USB game pads). For the motor to complete once cycle could be another 10 ms.  This is all conjecture as I can not find the information online but I promises you it is not less then 8ms. 

The reason the issue does not occur in 5.0 was not clear at first but after a bit of experimenting I see it is because the rumble is not as frequent as the beta version. So this is not really a bug but an enhancement gone wrong. However this enhancement is showing a bug that has been here for a long time. Hard to really call it a bug, but IMO just bad practice. 

Two solutions I would suggest. 

One, simply put the rumble after the usb poll event. 
or
Two, rumble less often. 

The only part I can not explain: Why the engine slows down? It does not seem to have anything to do with the adapter in question but it also is only Direct X HID based controllers. As far as the adapter is concerned the spamming of FFB is harmless. However If someone would implement my second solution, the problem would be much lessened. Though I feel this is only a band-aid to the slow down effect. 


Anyways, this is as much help as I can be. To reproduce the effect just spam the FFB direct X engine and you will see the result. You do not need the Bliss-Box adapter, this is apparently irreverent. X input and driver based adapters may not have the problem. I think its is the PID interface that HID uses that is choking dolphin.  


One extra thing I noticed was that if I send NAK instead of ACK for the USB output transfer the game skipping is greater. This makes sense of course because a NAK tells the host to hold off. It would seem that the FFB request is waiting for ACK. On any usb 1.1 you are looking at 8ms per poll and that will cause this effect. This is all mild guessing on my part but I would think this should be put in another processor thread? Force Feedback should not halt the code and wait for a response?

Also the rumble in this game is sending a string like : turn on rumble, turn on rumble, turn on rumble, turn on rumble, turn on rumble, turn on rumble, .....turn [b]off[b] rumble, I'm guessing this is for support odd ball controllers? Why not turn on rumble, ................................turn [b]off[b] rumble, ? - just an observation.

[ulao]

Hmm, ok two more bugs..

1) the rumble test does not send any data over the FFB engine. 5.0 does.
2) when this FFB spamming ends, the last command is turn on the rumble motor.  like so...
on,off, on,off, on,off, on,off, on,off, .....on (no off) so the controller just rumble endlessly.  I have prevention built in to my adapter so this does not happen but I noticed driver based adapter do. I attached a screen shot of that happening 

0a 01 01 01 means motor on  (or turn on constant force)
0a 01 03     means turn it off.    (or turn off constant force)

I guess I could add this
https://forums.dolphin-emu.org/Thread-dolphin-s-pad-plugins-wow-but-no-rumble-support?pid=261111#pid261111
Looks like this nik guy found the same to be true with spamming the FFB engine.

[ulao]

I was able to influence the way usb control data is sent in to rid of this issue. The fix started in 2.0 227. Bliss-Box will now accept FFB commands 1ms apart (shorter g in theory). Dolphin was observed at 3ms apart.