Setting the rumble motors in Update() using gamepad.SetMotorSpeeds(lowPower, highPower) results in 0.8ms of CPU time in a scene that takes around 5ms total. Considering I am running physics on 8 cars with 6 of their own child rigidbodies on hinges plus the complex math code, it didn’t seem right that just assigning rumble values to a controller should use so much CPU.
The controller is one of the new official Xbox controllers. I connect via bluetooth usually but decided to try USB. All of the sudden CPU usage for SetMotorSpeeds is 0.03ms. Seems IInputRuntime.DeviceCommand is blocking as it waits for a response from the controller that the command was recieved.
I appear to be having similar issues, using an Xbox Series controller wirelessly (with the official xbox wireless dongle) and unity 2022.3.15f1. Calling Gamepad.SetMotorSpeeds results in up to 10ms CPU spikes, while doing so with the controller connected via USB reduces it down to 2ms or less.
The solution is not to use Unity. When I reported the issue to Unity, they marked it as “Will not fix” or whatever. I even tracked down the single line of code that they would need to change. What a bunch of dummies
It’s been a long while and Unity deleted all their old bug reports so I can’t access any of my past old reports (as far I know). I believe it was in the chain of InputDevice.ExecuteCommand. Unity would tell the controller to vibrate and then, for some reason, wait for a response from the controller to say that it got the buzz buzz command before it would move on. So it locked up the main thread until a high latency bluetooth device gave it the A-ok that it got a command that doesn’t need a response in the first place. The only change that was required is not waiting on the response but that was too much work.