DS4Windows 🚀 - Latency Problem ds4w vs none

Ok dolphin issue is resolved, turned off "continuous scanning" in gamepad options.. but still main latency issue remains

IceLancerSR on 18 Nov 2019

Hmmmm... There is one difference when you use the controller with or without DS4Windows application over bluetooth (BT) connection.

DS4 gamepads have two operating modes in PC when connected over BT. The first one is a default _"PC-friendly mode"_ and this mode is what WindowsOS uses and you'll see when you test the gamepad without DS4Windows app. In this PC-friendly mode certain special features of DS4 gamepad like lightbar and touchpad don't work. This also means that the data packet sent over BT connection has a lot less data than a native DS4 mode.

When you use the gamepad with DS4Windows app then the app commands the gamepad to use _"Native DS4 mode"_ over BT (PS4 console does the same, but "pure" Windows PC doesnt know how to do it). In this native DS4 mode the gamepad sends a bit more data in BT HID datapackets.

Maybe your BT receiver/driver/something doesn't know how to handle the extra burden caused by native DS4 gamepad mode?

When you connect the gamepad using USB cable then there is no need to do this mode switch because DS4 gamepad goes automagically to native DS4 mode in USB connection (nothing to worry about throughput of USB connection).

Anyway. DS4Windows does not only read data from DS4 gamepad in native mode. It may also send data to DS4 gamepad to control rumble and lightbar. Try to set the rumble percent in a DS4Win profile down to 0% because this will disable rumble messages sent to a gamepad. Outgoing lightbar messages cannot be disabled but if you untick "flash lightbar in high latency" and "color by battery %" options then DS4Windows shouldn't periodically update lightbar color.

Maybe some BT chipset/devices/drivers die when BT line is used for both reading and writing data?

And it might be useful to test your PC/gamepad/BT setup with DS4Windows WITHOUT doing the ds4 native mode switch to see if it makes a difference. Let's see if I can create such a special debug version to diagnose the "theory of native DS4 mode switch in BT". I'll let you know through this issue thread if/when I have created such a special debug version.

mika-n on 19 Nov 2019

👍1

Alright what u said makes some sense. I must point out that i did turned off rumble and "light-bar" or at least i changed color of lightbar to black (not shining , if that constitutes as being turned off)
I am really looking forward to your debug version as this is driving me nuts, i can barely use gamepad right next to PC with ds4win. As for drivers, i used Asus drivers from their website.

IceLancerSR on 19 Nov 2019

I believe that I had a hacked version that kept the controller in PC mode around the 1.5 releases. Not much could be done with it other than checking the input latency reading. I believe it actually reads at 8 ms when in PC mode when connected via BT. I think I left the controller in PC mode by neglecting to send any output reports to the DS4.

For me, DS4Windows actually provides a snappier experience than even using the original DirectInput interface despite the emulation layer. It might be more a matter of reducing the size of the input buffer rather than switching the controller to native DS4 mode.

Ryochan7 on 19 Nov 2019

@Ryochan7 does battery levels and color control also affected by this? I mean i could easily live without those things if it could mean better latency
Or maybe attack debug to all requests to see which one is affecting the most?

IceLancerSR on 19 Nov 2019

I'm interested in this , I have the same problem for like a year more o less

cristianmars on 20 Nov 2019

@IceLancerSR and @cristianmars Please download the new version of DS4Windows_DeviceDetectDebug version from the following link:
https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

This new debug version has two EXE files. The first one is a normal DS4WindowsDebug.exe debug version which dumps looots of detailed log messages about DS4 gamepad handshaking and connections. This one does the usual "PC Friendly -> DS4 Mode Switch Over" thing as usual.

The zip file has another identical EXE but the filename is DS4WindowsDebug_NoDS4Mode.exe. This debug version does the same as the normal debug version except DS4 mode switch command is not sent to a gamepad (USB connection works normally because mode switch is required only in BT mode). In this version all buttons and analog sticks work, but touchpad/lightbar/rumble doesn't work because of PC-friendly gamepad mode.

At first the NoDS4Mode shows few extra warning messages that incoming HID message was in unexpected format. No need to worry about those because after few seconds the debug version falls back to handle incoming HID BT gamepad messages as it was in PC-friendly mode.

Are there any significant differences in lag and BT range between the normal debug version (or the normal official DS4Windows.exe) and the NoDS4Mode debug version?

NOTE! When you test the NoDS4Mode then make sure to switch off the DS4 gamepad and preferably toggle off/on bluetooth in PC to make sure that the system doesn't remember previous DS4 switch state.

mika-n on 20 Nov 2019

@mika-n
i tested it, result is marvelous!
It works identical as my test without ds4win. No input lag at all. 2m away

Edit, ok not identical , there is slight loss at 1.8meters. But distance has tremendously increased!
So which one those removed can safely be removed without breaking good functions, like touch pad ?

IceLancerSR on 20 Nov 2019

P.S i just noticed that battery levels are showing 0% , i guess they dont work either in "friendly mode" ?
If i were betting man, i would bet on those batt levels checks to be major cause for input latency and since i dont know how color levels actually work, but i assume that is is constantly sending checks to gamepad to keep specific colors?

IceLancerSR on 20 Nov 2019

P.P.S
Gyro is also not working :( thats major setback> padtest recognizes gyro , and it hooks to it, but thats it, it doesnt show any movement

And last note, idle disconnect also doesnt work

IceLancerSR on 20 Nov 2019

That's interesting. Just out of curiosity, have you checked vanilla DS4Windows using a BT Poll Rate of 8 ms in a profile? Also, can you check out the latest WPF beta build and see if you run into problems with it? Make sure to extract it into a different location than the current DS4Windows.

https://drive.google.com/file/d/1Nu2gJhGx9ZDQ1gnQP1qU2LwgPqjVvTyj/view?usp=sharing

Ryochan7 on 20 Nov 2019

@Ryochan7 i did try 8ms pool rate , it didnt change anything or at least it looked that way, latency was still massive.
Ill take a look at WPF build now

IceLancerSR on 20 Nov 2019

Tested WPF build. Latency is marginally better then vanila ds4win. But still not acceptable, latency goes sky high by jiggling gamepad in spot in 1 meter distance. Also happens while gamepad is standing still on table ,latency would randomly spike

IceLancerSR on 20 Nov 2019

Last note in DS4WindowsDebug_NoDS4Mode test.
NoDS standing still on table 1m away = input delay 1ms . attempt to move further, latency stays at 1-3ms untill 1.8meters then slight loss starts to happen but only under certain angles, varies 2-12ms
DS4vanila same position = 4=14 jumping up down attempt to move further latency goes sky high red

My hope is that , maybe? we could turn off non essential components while bluetooth is in use? lightbar, vibration,battery status (maybe something else too, i cant tell what is affecting the most) and turn back on when on usb?

IceLancerSR on 20 Nov 2019

Thank you for checking out the WPF beta. So the difference in some property change updates, like battery status, didn't make a difference. I will have to take a look at the archive that mika posted and the source repo. Did you try DS4WindowsDebug.exe as well as DS4WindowsDebug_NoDS4Mode.exe?

Ryochan7 on 20 Nov 2019

Yes i did. Debug version behaves identical to vanila. it just generated some additional log data. No effect on latency in any way

IceLancerSR on 20 Nov 2019

@mika-n
if you could find way to enable touchbar and gyro in your NoDS .exe i belive that could serve good.

IceLancerSR on 20 Nov 2019

Debug version is based on the latest V1.7.22 vanilla version. Also, the DS4WindowsDebug_NoDS4Mode.exe is identical binary file with DS4WindowsDebug.exe. This debug version does a brute force "if process filename is xxx_NoDS4Mode.exe then don't do DS4 mode switch in BT" trick, so that's why both debug versions are binary identical.

Relating to this "ignore ds4 mode switch" change the most important commit changes in DebugVer branch are the following two lines. Most of the other changes in this DebugVer commit are just bunch of debug outputs or stupid whitespace commit diffs.
https://github.com/mika-n/DS4Windows/commit/c6d9505939c775fc5c45d504a46c917b406e9cdb#diff-0eb645af0d0308cd1787efcca407535dR509
https://github.com/mika-n/DS4Windows/commit/c6d9505939c775fc5c45d504a46c917b406e9cdb#diff-0eb645af0d0308cd1787efcca407535dR1251

Also one more important change in order to support PC-friendly mode in BT connections. DS4Device.performDs4Input method has bunch of warning messages about invalid and unexpected received BT hid message buffer. The vanilla version would simply drop all unexpected BT hid messages. HID messages in PC-friendly mode would be dropped also. This is why the following changes have been made in perormDs4Input method to at first show 5 warning messages about dropped HID messages. After the 6th unexpected incoming hid message the debug version starts to accept 0x01 pc-friendly hid messages and handles those as required (ie. button and ls/rs data is in different index position than in 0x11 DS4 hid buffers).
https://github.com/mika-n/DS4Windows/blob/debugVer/DS4Windows/DS4Library/DS4Device.cs#L776

mika-n on 20 Nov 2019

@mika-n
if you could find way to enable touchbar and gyro in your NoDS .exe i belive that could serve good.

Those features are part of the "DS4 mode", so touchpad and gyro are not possible without doing DS4 mode switch in BT (ie. DS4 gamepad won't send that data in HID messages to a client PC machine in PC-friendly mode). Also, rumble and lightbar are not supported in PC-friendly mode (actually the first attempt to send rumble and lightbar data from a PC to DS4 gamepad would do the mode switch in BT). Battery indication value is also part of the DS4 mode HID messages, so it is not possible to enable these features one by one in DS4 gamepad.

But, it would be possible to enable DS4 mode and at the same time tweaking the debug version to do less frequent HID report writing (outgoing messages from PC to DS4 gamepad) and trying to see is there something weird in DS4Windows how it handles this extra data (ie. reading those extra features from DS4 gamepad but not feeding those values forward in DS4Windows app specific data streams). Hmm.. This needs a bit more thinking how and what to debug....

mika-n on 20 Nov 2019

👍1

@mika-n
Thanks , right now i am very much enjoying lag free gamepad all the way from my couch :) (thanksto your NoDS)
Looking forward to see what u come up with that new idea , to lower latency on full featured ds4

IceLancerSR on 20 Nov 2019

This debug version does a brute force "if process filename is xxx_NoDS4Mode.exe then don't do DS4 mode switch in BT" trick, so that's why both debug versions are binary identical.

That explains why the lightbar still worked at first. I renamed the exe to DS4Windows.exe before trying it out. Using a different exe name does change some aspects of the program. The DS4Windows.exe.config file will not be used anymore so workstation garbage collection will be used by the .NET Runtime rather than server mode GC. Language packs will no longer be found either as the Lang directory will no longer be in the assembly probing path.

Anyway, input delay readings jump between 4 - 6 ms on my machine when using NoDS4Mode. Normal Debug stays in between 3 - 4 ms.

Ryochan7 on 20 Nov 2019

Funny enough, playing with the analog sticks causes the input delay reading to decrease in NoDS4Mode. The reading will jump between 1 - 2 ms. The input delay number starts to increase again after some inactivity.

Ryochan7 on 20 Nov 2019

Now I did the test with a renamed exe config file. I changed the file to DS4WindowsDebug_NoDS4Mode.exe.config so .NET would use it for NoDS4Mode. Still experiencing the same behavior.

Ryochan7 on 20 Nov 2019

Now I did the test with a renamed exe config file. I changed the file to DS4WindowsDebug_NoDS4Mode.exe.config so .NET would use it for NoDS4Mode. Still experiencing the same behavior.

dont know, thats very weird what u are experiencing. i am second hour now already playing dolphin baldurs gate, latency is marvelous, no issues at all (NoDS exe)

IceLancerSR on 20 Nov 2019

Checking CPU usage while only browsing the main Controllers tab shows that usage can jump up to 3.5% at times of activity. The normal DS4Windows would only jump to a little over 3% when using the Max setting for BT Poll Rate. CPU usage can get to around 1.5% when using the normal 4 ms BT Poll Rate.

Ryochan7 on 20 Nov 2019

Hello i was at work sorrry for coming late , so i tried both debug vercions with ds and without and the WPF , all of them gave me latency i have the log from the debug in case you want to take a look.

Debug test.txt

cristianmars22 on 21 Nov 2019

@cristianmars22 u were suppose to test DS4WindowsDebug_NoDS4Mode.exe not regular debug from @mika-n post

IceLancerSR on 21 Nov 2019

its the same i got hit with latency over 10 ms almost instantly

cristianmars22 on 21 Nov 2019

NoDS

its the same i got hit with latency over 10 ms almost instantly

check if u have done it properly.
if ur battery is showing anything but 0 then u didnt

IceLancerSR on 21 Nov 2019

okey thanks for the tip about that ! , cheking again now im gonna play a couple of minutes to see how it goes.

cristianmars22 on 21 Nov 2019

Dont delete original vanila ds4windows, just drag and drop new exe files in same folder.
Right click then exit active ds4windows from tray. turn off gamepad/cycle bluetooth connection.
Start using new Exe with NoDS4Mode in name. Connect gamepad.
batt

P.S
its time for me to sleep,night

IceLancerSR on 21 Nov 2019

well i tried all three vercions that mika and ryo provided , even with the instructions i deleted the controller changed the bluethoot adapter to a usb 3.0 repaired the controller started the NoDs debug paired the controller , checked that is okey because batery was showing 0% and stil got latency after a couple of minutes .i really dont know whats going on

cristianmars22 on 21 Nov 2019

Funny enough, playing with the analog sticks causes the input delay reading to decrease in NoDS4Mode. The reading will jump between 1 - 2 ms. The input delay number starts to increase again after some inactivity.

i was cheking the controller readdings and got the exact same behavior , with the delay decreacing and everything, and after moving the sticks and pushing buttons the latency spikes starts to appear. Also cheking the cpu usage of ds4 windows , when i start moving the sticks it goes to 6.5% after a sec goes down to 3.5 - 2.6 % and if you let it be it goes way down to 0.4 - 0,0 % and thats when latency goes everywhere until you gave an input and stabilize itself but cpu usage is all over the place.

cristianmars22 on 21 Nov 2019

https://youtu.be/4iPE4lmhw_A

IceLancerSR on 21 Nov 2019

https://youtu.be/4iPE4lmhw_A

hows cpu usage during this ?

cristianmars22 on 21 Nov 2019

https://youtu.be/4iPE4lmhw_A

hows cpu usage during this ?

https://youtu.be/BvvMRMkvuLc

IceLancerSR on 21 Nov 2019

https://youtu.be/4iPE4lmhw_A

hows cpu usage during this ?

https://youtu.be/BvvMRMkvuLc

oh wow a lot more stable than mine...

cristianmars22 on 21 Nov 2019

https://youtu.be/4iPE4lmhw_A

hows cpu usage during this ?

https://youtu.be/BvvMRMkvuLc

oh wow a lot more stable than mine...

i am dead tired :(
dont know what to tell you.. only difference i can think of but i cant test now is the fact that i am using old 2009 driver for emulated xbox gamepad, in order to fix my guide button not working after removing xbox services from windows
I also dont use hidguardian

IceLancerSR on 21 Nov 2019

Tried a few things. Should have thought about it before but having controller readings still show up in the tab means that the input report change happened. It is still technically in DS4 mode. Also, the DirectInput controller no longer works.

It turns out that reading the calibration data can change the input report type given by the controller. The extra features are still not available at that point though. Skipping the run calibration step ensures the original report type is still sent and the DirectInput controller still works. Of course that means controller readings won't happen in DS4Windows and the mapping routine is never reached.

I also confirmed my hypothesis. Decreasing the input buffer for the HID device from within DS4Windows affects the DirectInput controller as well. It stays in affect even after quitting DS4Windows. The normal DirectInput controller becomes much more responsive than normal.

Ryochan7 on 21 Nov 2019

i was cheking the controller readdings and got the exact same behavior , with the delay decreacing and everything, and after moving the sticks and pushing buttons

I noticed this too in normal debug and in the NoDS4Mode debug versions. This is veeeery strange. One factor could be "workstation vs server .NET garbage collecting" mode difference because by default debug versions run in workstation GC mode unless DS4Windows.exe.config file is copied as DS4WindowsDebug_NoDS4Mode.exe.config file also as Ryochan7 pointed out.

There are some unnecessary buffer copies made during HID report handling in BT, so those should be eliminated to avoid wasting CPU cycles and causing RAM fragmentation in .NET framework. These HID readings and writings happen frequently in a background thread, so few wasted cycles there may be a big thing in the long run.

Tried a few things. Should have thought about it before but having controller readings still show up >in the tab means that the input report change happened. It is still technically in DS4 mode. Also, the > It turns out that reading the calibration data can change the input report type given by the >controller.

Yes. Sending the calibration request over BT makes the DS4 mode switch. That's why xx_NoDS4Mode.exe debug version skips the gyro calibration if the gamepad is connected over BT. And NoDS4Mode.exe doesn't send out rumble/lightbar HID write messages because those would also make the mode switch.

NoDS4Mode supports re-map and readings and virtual output driver in BT mode but that is because of the changes in performDS4Input method to accept "non standard DS4 HID data packets" as pointed out in my earlier post.
https://github.com/Ryochan7/DS4Windows/issues/896#issuecomment-556328580

I also noticed that if the gamepad was switched to DS4Mode then it may remain in that state even when DS4Windows app is re-started. Readings tab can be used to verify this because if gyro shows any activity then the gamepad must still be in DS4 mode. During my tests I had to press PS button for about 5-10secs to force shutdown the gamepad and toggle off/on bluetooth in PC to make sure that a new test started as "fresh gamepad" (gamepad mode in DS4 and WirelessController device handle in PC).

I also confirmed my hypothesis. Decreasing the input buffer for the HID device from within

Hmmm..... NoDS4Mode debug version didn't change the HID buffer size used while reading incoming HID reports. I'll test this theory and change the NoDS4Mode to use "standard PC-friendly" HID buffer size to see if that makes a difference.

However, all this stil doesn't mean that the BT lag problem in DS4Mode is solvable purely in software side. If the BT chipset in a PC is somehow unable to handle the extra data sent in DS4Mode HID report data packets then it could be PC/BT/chipset issue.

Maybe I have to create a debug version where it is possible to selectively set any combination of certain things to happen or not to happen:

Calibration of gyro enabled/disabled (related to DS4 mode switch)
Sending rumble and lightbar OUTGOING (pc->ds4 gamepad) hid data packets enabled/disabled (related to DS4 mode switch)
Changing the size of incoming HID report buffer request (PC friendly 0x01 vs DS4Mode 0x11 HID size).
Feeding incoming gyro/battery/touchpad data forward in DS4Win app data stream logic (ie. even if DS4Mode would be selectively enabled then this option would remove that data from being seen by DS4Win app. This might tell us if there is something strange in how DS4Win app handles these events).

There is one slight difference in how DS4Mode and PCFriendly mode behaves in DS4 gamepad. If ds4mode is enabled then DS4Windows app commands the DS4 gamepad to use certain HID data update frequency (BT). This value comes from the BT update interval config option in DS4Win. If gyro calibration is skipped (like is done in NoDS4Mode debug version) then the gamepad uses a default update frequency (what is it? dont know exactly). This could have a big impact on how BT behaves between the gamepad and PC. Being able to selectively enabe/disable gyro calibration and outgoing HID message writes would make it possible to use DS4Mode with or without default frequency. I will create a new version of the debug version where you can selectively enable/disable certain features. It might be interesting to know if it is a certain specific feature causing increasing lag in BT.

mika-n on 21 Nov 2019

I glanced over your code and missed that the RefreshCalibration method had the assembly check. I also missed that there is the check for PC mode in the input report parsing code. The NoDS4Mode exe does work while keeping the DirectInput interface active. I carried over some of the changes to the vanilla jay code base for testing.

The relevant line where the HID buffer count is decreased is contained in the DS4Device.performDs4Input method and consists of the following:

NativeMethods.HidD_SetNumInputBuffers(hDevice.safeReadHandle.DangerousGetHandle(), 2);

https://github.com/mika-n/DS4Windows/blob/debugVer/DS4Windows/DS4Library/DS4Device.cs#L781

There is definitely a difference between when that call is left in and when that call is commented out of the code. Now having seen this, it might be time to test the input latency difference between the tweaked DirectInput device and an emulated controller.

Ryochan7 on 21 Nov 2019

@mika-n you need us to do more testing ? I have no problem with it

cristianmars on 21 Nov 2019

@IceLancerSR and @cristianmars Please download the latest DeviceDetectDebug version.
https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

Now it supports certain configuration options in DS4WindowsDebug.exe.config file to selectively enable or disable certain features. Now there is no need to xxx_NoDS4Mode.exe at all because this config file makes it possible to try difference scenarios using the same debug app.

If both GyroCalibration and SendRumbleLightbarData are disabled then the gamepad stays in PC-friednly mode (ie. DS4Win app won't do DS4 mode switch in BT. USB is always in ds4 mode).

I'm especially interested to hear how the lag and BT behaves in your setups when following debug combinations are used (restart DS4WindowsDebug.exe app after changing the config options. And when trying to test DS4 mode vs PC-friendly mode then DS4 gamepad needs to be shutdown by holding PS button and preferably bluetooth in PC toggled off/on to clean up the previous ds4 state):

Test 1: Gamepad stays in PC-friendly mode (special DS4 features not available)

GyroCalibration and SendRumbleLightbarData options FALSE
ReadGyroData/ReadTouchpadData/ReadBatteryData options FALSE

Test 2: Gamepad in DS4 mode, but gyro/touchpad/battery data is not feed to DS4Win app itself.

GyroCalibration and SendRumbleLightbarData options TRUE
ReadGyroData/ReadTouchpadData/ReadBatteryData options FALSE

Test 3: Gamepad in DS4 mode, but rumble and lightbar data is not sent to ds4 gamepad.

GyroCalibration option TRUE
SendRumbleLightbarData option FALSE
ReadGyroData/ReadTouchpadData/ReadBatteryData options TRUE (or enabled one by one)

Test 4: Gamepad in DS4 mode, but gyro/touchpad/battery data options enabled one by one.

GyroCalibration and SendRumbleLightbarData options TRUE
ReadGyroData/ReadTouchpadData/ReadBatteryData options FALSE one by one (ie. one option FALSE, other two TRUE)

The last debug option is Debug_HidDSetNumInputBuffers and this has a special meaning. It is used to change how HID input buffers are initialized. By default DS4Win app uses 2 buffers, but I'm interested to hear how BT behaves in your setup (while GyroCalibration and SendRumbleLightbarData are enabled) when this value is set to 0 (ie. DS4Win doesn't try to change the num of input buffers from WinOS defaults). Or how it works with values 1 or 3 compared to default value 2.

<appSettings>   
  <!-- Debug_xx = Debug options to enable/disable/tweak certain features of DS4Windows app -->
  <!--   false = Disabled, true = Enabled. The default value in this file is the normal DS4Windows behaviour -->
  <add key="Debug_GyroCalibration"             value="true" />
  <add key="Debug_SendRumbleLightbarData"      value="true" />
  <add key="Debug_ReadTouchpadData"            value="true" />
  <add key="Debug_ReadGyroData"                value="true" />    
  <add key="Debug_ReadBatteryData"             value="true" />  

  <!--   0 = Don't set custom number of HID buffers (use Win defaults). >0 Num of incoming HID buffers (default in DS4Windows app is 2 -->
  <add key="Debug_HidDSetNumInputBuffers"      value="2" />    
</appSettings>

https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

mika-n on 21 Nov 2019

Windows only allows a minimum of 2 buffers so using a value of 1 is not an option. I guess it makes sense that there should be at least two input buffers in the queue. The default number of input buffers for the HID class is supposed to be 32 according to the docs. The maximum number that is supported on Windows XP and later is 512.

https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/hidsdi/nf-hidsdi-hidd_setnuminputbuffers

I will also download the latest debug version and try it out.

Ryochan7 on 22 Nov 2019

Windows only allows a minimum of 2 buffers so using a value of 1 is not an option. I guess it makes sense that there should be at least two input buffers in the queue. The default number of input buffers for the HID class is supposed to be 32 according to the docs. The maximum number that is supported on Windows XP and later is 512.

https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/hidsdi/nf-hidsdi-hidd_setnuminputbuffers

I will also download the latest debug version and try it out.

I can do half of the testing tonight I think how do you recommend going about that part ?

cristianmars on 22 Nov 2019

@mika-n Okey so i finished testing all of the scenarios , my method of testing was doing 5 minutes runs on dark souls 3 on a small area repeating so the conditiosn are more or less the same i have all the logs

Test 1..txt
Test 2.txt
Test 3 - A.txt
Test 3 - B.txt
Test 3 - C.txt
Test 4 - A.txt
Test 4 - B.txt
Test 4 - C.txt
Test 5 - A.txt
Test 5 - B.txt

the variables mean the sub conditions you gave me for example:

For A:
GyroCalibration option TRUE
SendRumbleLightbarData option FALSE
ReadGyroData TRUE
ReadTouchpadData FALSE
ReadBatteryData FALSE

For B:
GyroCalibration option TRUE
SendRumbleLightbarData option FALSE
ReadGyroData FALSE
ReadTouchpadData TRUE
ReadBatteryData FALSE

and for the input buffer settings given what ryochan said i tried on a value of 0 and 3, because i already tested everything on 2

an so on ... between testing what i do is this process for all the times : turn off gamepad holding the home button , close ds4 windows , turn off bluetooth, export log , edit the config file , turn on bluetooth , open ds4 windows , turn on gamepad and star testing session.

One more thing i got little results with input lag the first time i gont latency the second i turned on the game pad and thougth that something was wrong so i unparied it from windows and did all the process again and still got a little of input lag after that almost nothing , but this problem has a history of going away after turning off and on the gamepad maybe i need to test longer sessions of gameplay. Im thinking that maybe what is causing some sort of problem is instead of turning of the controller by holding the home button i always doit from the macro of home plus options button i dont have more time to test this maybe tomorrow.

so there is that hope it helps .

cristianmars22 on 22 Nov 2019

👍1

@cristianmars22 Thanks for the test run. Looks like most tests were "lag free" but on the other hand not clear what exactly "fixed it". Was it re-pairing the device in Windows or shutting down the gamepad completely before re-connecting it (ie. holding down PS button for 5-10 secs)? Or was it some of those disabled/enabled debug flags?

Debug_HidDSetNumInputBuffers option may have significant impact on perceived lag on some systems. The default buffer size of 2 used by DS4Win app is the minimum buffer and doesn't leave much room for a random BT radio interference. Increasing this buffer (or setting it to zero and this way using WinOS default value) may help in some systems. Difficult to say how Windows handles DS4 gamepad when used in PC-friendly mode without DS4Windows app, but I'm ready to believe that WinOS uses the documented default size of 32 (as shown in the Win API docs linked by Ryochan7).

Maybe this HidDSetNumInputBuffers option should be added to a vanilla version of DS4Windows. Somewhere in general settings screen because this is probably not a profile specific option (don't see why different profiles in the same PC might wanna use different value).

@IceLancerSR Did you find time to test the latest debug version and different debug options? And maybe you should also try to unpair the gamepad in WinOS, to force shutdown the gamepad by pressing PS button for 5-10secs before re-pairing it (or event pressing reset button on the backside of the gamepad in a little hole)?

mika-n on 23 Nov 2019

sorry guys i am soo drugged after dentist i am not my sel..going to bed.

IceLancerSR on 23 Nov 2019

ok i did one test, touchpad on ,others off.
First thing i noticed is that battery status is turned ON (partially =shows batt 100%) when i enable touchpad only.
My conclusion is that u were on the right track. Increasing Debug_HidDSetNumInputBuffers to 3 reduced latency to be proper! Putting it to 2 there was latency issue ,going more down to 0 , greatly increased latency up to a point of not usable
Test on table 1.5m and 2meters away.
buffer 3= gamepad is good native ds almost if not exact
buffer 2 = slight latency issue , 15-20% dropout then the above
buffer1-0 latency would rise break limmits and loose connection greatly

i will do some retests just to make sure

IceLancerSR on 23 Nov 2019

Yup confirm above, i cant explain it, thats up to you.
But buffer 3 offers greater results over buffer 2. Bufffer 2 breaks latency immediately and packets loss is noticeable contrary to buffer 3 which seems to be working good

IceLancerSR on 23 Nov 2019

Debug_ReadGyroData =true
doesnt seem to be doing anything? gyro is not working.
enabling Debug_GyroCalibration =true on top results in gyro working but MASSIVE latency. standing on table still, latency is 6 and on to red, attempting to move analog seems to briefly reduce latency ? and latency becomes inconsistent after that. Letting analog go ,leave gamepad to stand still,latency increases again? This are weird results , why would analog movement reduce latency ?

IceLancerSR on 23 Nov 2019

OMH! it isnt analog that is causing that weird inconsistent latency , its hand position on gamepad that changes with thumb movement. covering and uncovering part of gamepad where grip is and arround analog controls result in latency changes. So its not analog that is responsible for that. Anyway
results is that enabling gyro tremendously increases latency , thats why hand movement over and arround gamepad were observed, latency increased very much becoming susceptible to minor movements like hand or finger
atm :
Debug_GyroCalibration" value="true
Debug_SendRumbleLightbarData" value="false
Debug_ReadTouchpadData" value="true
Debug_ReadGyroData" value="true
Debug_ReadBatteryData" value="false

IceLancerSR on 23 Nov 2019

Lightbar:
Enabling lightbar (alone , no others) control again increases latency in standing still state, increases further with moving to distance
Latency is even higher then using Gyro.

IceLancerSR on 23 Nov 2019

Debug_ReadBatteryData alone does not seem to have any effect on latency But battery status shows 0?
Ok in order to have functional battery status, lightbar needs to be turned on as well.
standingstill latency =4 , not nearly as high as gyro , but still high 40-50% loss

IceLancerSR on 23 Nov 2019

Conclusion :
touchpad data= no loss but havent tested functionality (tested, doesnt work, requires Debug_SendRumbleLightbarData to be enabled, ...testing latency)

batterydata= no loss but doesnt work , lightbar needs to be enabled as well , then loss is observed. between 40-50%
gyrodata =no loss but gyro calibration is necesary for gyro to work= result is massive latency

End results, cant get 100% accurate data, because touchbar and battery status data both require Debug_SendRumbleLightbarData to be enabled in order to function.

Enabling Debug_SendRumbleLightbarData results in up to 50% latency increase. If possible separate that so touchpad and battery could be tested properly?

Gyro seemed to be highest drainer of all

IceLancerSR on 23 Nov 2019

@cristianmars22 Thanks for the test run. Looks like most tests were "lag free" but on the other hand not clear what exactly "fixed it". Was it re-pairing the device in Windows or shutting down the gamepad completely before re-connecting it (ie. holding down PS button for 5-10 secs)? Or was it some of those disabled/enabled debug flags?

Debug_HidDSetNumInputBuffers option may have significant impact on perceived lag on some systems. The default buffer size of 2 used by DS4Win app is the minimum buffer and doesn't leave much room for a random BT radio interference. Increasing this buffer (or setting it to zero and this way using WinOS default value) may help in some systems. Difficult to say how Windows handles DS4 gamepad when used in PC-friendly mode without DS4Windows app, but I'm ready to believe that WinOS uses the documented default size of 32 (as shown in the Win API docs linked by Ryochan7).

Maybe this HidDSetNumInputBuffers option should be added to a vanilla version of DS4Windows. Somewhere in general settings screen because this is probably not a profile specific option (don't see why different profiles in the same PC might wanna use different value).

@IceLancerSR Did you find time to test the latest debug version and different debug options? And maybe you should also try to unpair the gamepad in WinOS, to force shutdown the gamepad by pressing PS button for 5-10secs before re-pairing it (or event pressing reset button on the backside of the gamepad in a little hole)?

for me it seems to be shuting down the controller by holding the home button , could it be something wrong with the macro ? or why is it that restarting it help to eliminate latency ?

cristianmars22 on 23 Nov 2019

@cristianmars22 I didnt notice anything like u describe. Maybe because i have nothing on system that could attach it self ? During test i even turned off nvidia. Command:
net stop NVDisplay.ContainerLocalSystem

i suggest trying that
to start again:
net start NVDisplay.ContainerLocalSystem

What probably happens, on system startup u start ds4 it takes over exclusively gamepad, but on turn off/reconnect, something hijacks gamepad before ds4win ?

IceLancerSR on 23 Nov 2019

@cristianmars22 I didnt notice anything like u describe. Maybe because i have nothing on system that could attach it self ? During test i even turned off nvidia. Command:
net stop NVDisplay.ContainerLocalSystem

i suggest trying that
to start again:
net start NVDisplay.ContainerLocalSystem

What probably happens, on system startup u start ds4 it takes over exclusively gamepad, but on turn off/reconnect, something hijacks gamepad before ds4win ?

i have seen that process and i was thinking if that maybe could cause inteference but i didnt know if i could close it

cristianmars22 on 23 Nov 2019

@cristianmars22 I didnt notice anything like u describe. Maybe because i have nothing on system that could attach it self ? During test i even turned off nvidia. Command:
net stop NVDisplay.ContainerLocalSystem
i suggest trying that
to start again:
net start NVDisplay.ContainerLocalSystem
What probably happens, on system startup u start ds4 it takes over exclusively gamepad, but on turn off/reconnect, something hijacks gamepad before ds4win ?

i have seen that process and i was thinking if that maybe could cause inteference but i didnt know if i could close it

Its absolute gamepad hijacker
Its safe to turn off using command i gave u above, type it in cmd promt with admin privileges. For a lot of times i even play with it being turned off without any noticeable bad sideeffects. It does however turns off access to nvidia control menu, but doesnt change its functionality

IceLancerSR on 23 Nov 2019

@cristianmars22 I didnt notice anything like u describe. Maybe because i have nothing on system that could attach it self ? During test i even turned off nvidia. Command:
net stop NVDisplay.ContainerLocalSystem
i suggest trying that
to start again:
net start NVDisplay.ContainerLocalSystem
What probably happens, on system startup u start ds4 it takes over exclusively gamepad, but on turn off/reconnect, something hijacks gamepad before ds4win ?

i have seen that process and i was thinking if that maybe could cause inteference but i didnt know if i could close it

Its absolute gamepad hijacker
Its safe to turn off using command i gave u above, type it in cmd promt with admin privileges. For a lot of times i even play with it being turned off without any noticeable bad sideeffects. It does however turns off access to nvidia control menu, but doesnt change its functionality

well i rarely acceses that menu anyway and if its causing problems i dont mind having it turned off, gona try to play an intensive while having it off

cristianmars22 on 23 Nov 2019

before nvidia were using separate overlay function which could be turned off in nvidia experience, but in new driver packs, nvidia experience has been removed as separate and its functions moved directly into driver. That is hijacker . By turning off nvidia local system u basiclly turn off software part of it. Which normally one doesnt need? Or at least i havent noticed problems with it being turned off

IceLancerSR on 23 Nov 2019

i shut down all nvidia container services to see if it will make a diference so im gonna do a test run now

cristianmars22 on 23 Nov 2019

i shut down all nvidia container services to see if it will make a diference so im gonna do a test run now

U just need to shutdown one with command
net stop NVDisplay.ContainerLocalSystem

http://www.imatest.com/2017/01/how-to-determine-what-processes-are-using-a-device/
basically this
find what is taking over your gamepad

IceLancerSR on 23 Nov 2019

i shut down all nvidia container services to see if it will make a diference so im gonna do a test run now

U just need to shutdown one with command
net stop NVDisplay.ContainerLocalSystem

http://www.imatest.com/2017/01/how-to-determine-what-processes-are-using-a-device/
basically this

got it now its only ds4 windows that is ussing it , the weird thing tho is that my controller apears with a little clock on the icon .

cristianmars22 on 23 Nov 2019

Dont worry about that, means nothing, just windows doing his checking
P.S windows store is also hijacker. Unless ur pc has modified to turn off background processes on close. So i suggest monitoring hijacks on reconnecting

IceLancerSR on 23 Nov 2019

Dont worry about that, means nothing, just windows doing his checking
P.S windows store is also hijacker. Unless ur pc has modified to turn off background processes on close. So i suggest monitoring hijacks on reconnecting

i had store removed a long time ago with the debloat script , so i dont think that is a problem

cristianmars22 on 23 Nov 2019

well no it still has latency spikes after a while so i guess nvidia wasnt at fault here

cristianmars22 on 23 Nov 2019

well no it still has latency spikes after a while so i guess nvidia wasnt at fault here

"After a while" or "on reconnect" ?
those are two very different things. Nvidia only affects gamepad "on reconnect" i dont know what could be causing ur other thing

IceLancerSR on 23 Nov 2019

well no it still has latency spikes after a while so i guess nvidia wasnt at fault here

"After a while" or "on reconnect" ?
those are two very different things. Nvidia only affects gamepad "on reconnect" i dont know what could be causing ur other thing

no after a while im trying the conditions that mika n gave us but on loger sessions now , disabling gyro sees to make it really good for now

cristianmars22 on 23 Nov 2019

First thing i noticed is that battery status is turned ON (partially =shows batt 100%) when i enable touchpad only.

If Debug_ReadBatteryData=FALSE then battery level is reported as 100% dummy value.
However, if both GyroCaliration=FALSE and SendRumbleLightbarData=FALSE then the gamepad stays in PC-friendly mode and DS4 gamepad doesn't send a battery status at all to PC in HID data packets. If "Debug_ReadBatteryData=TRUE" in this scenario then I'm not sure how DS4Windows reports battery level (some random or 0% level always?).

If both Debug_GyroCalibration and Debug_SendRumbleLightbarData are FALSE then gyro, lightbar, battery and touchpad data is not available at all because those are not part of PC-friendly HID data packets. If one of those or both are TRUE then DS4Windows tries to switch the gamepad to DS4 mode and then those extra features are available.

Debug_ReadGyroData=true doesnt seem to be doing anything? gyro is not working.

Yes. If the gamepad is NOT in DS4 mode in BT (ie. both GyroCalibration and SendRumbleLightbar options are set to FALSE) then ReadGyroData/ReadBattery/ReadTouchpad options don't do anything because those extra features are not available in PC-friendly gamepad mode. At least one of the GyroCalibration and SendRumbleLightbar needs to be enabled to switch over to DS4 mode and to use extra features.

Are those gamepads working just fine with PS4 console over BT connection? I don't have any explanation why enabling GyroCalibration would cause massive lag. Faulty gamepad? A bug in calibration routine in DS4Windows?

If disabling gyro helps then is the "Debug_GyroCalibration=FALSE" option or "Debug_ReadGyroData=FALSE" option?
If it is Debug_GyroCalibration=FALSE and Debug_ReadGyroOption=TRUE (well gyro reading dont have any actual meaning without calibration) option then there may be some issue in calibration routine or gamepad is faulty.
If Debug_GyroCalibratino=TRUE and Debug_ReadGyroData=FALSE fixes the issue then there may be a bug in DS4Windows gyro handling (an exception thrown during gyro data calculations?)

If HidDSetNumInputBuffers=2 option causes lag then it may be that BT chipset in PC and DS4Windows app cannot read and process incoming BT messages fast enough and messages are lost. NumOfInputBuffers=3 gives a bit more head room for BT stack to pool incoming data packets. Well, any PC should be fast enought handle these HID BT messages, but if there is a hidden bug in DS4Windows app and it keeps throwing exceptions (but don't log those in a logfile) then it could cause massive slowdown of the app.

mika-n on 23 Nov 2019

First thing i noticed is that battery status is turned ON (partially =shows batt 100%) when i enable touchpad only.

If Debug_ReadBatteryData=FALSE then battery level is reported as 100% dummy value.
However, if both GyroCaliration=FALSE and SendRumbleLightbarData=FALSE then the gamepad stays in PC-friendly mode and DS4 gamepad doesn't send a battery status at all to PC in HID data packets. If "Debug_ReadBatteryData=TRUE" in this scenario then I'm not sure how DS4Windows reports battery level (some random or 0% level always?).

If both Debug_GyroCalibration and Debug_SendRumbleLightbarData are FALSE then gyro, lightbar, battery and touchpad data is not available at all because those are not part of PC-friendly HID data packets. If one of those or both are TRUE then DS4Windows tries to switch the gamepad to DS4 mode and then those extra features are available.

Debug_ReadGyroData=true doesnt seem to be doing anything? gyro is not working.

Yes. If the gamepad is NOT in DS4 mode in BT (ie. both GyroCalibration and SendRumbleLightbar options are set to FALSE) then ReadGyroData/ReadBattery/ReadTouchpad options don't do anything because those extra features are not available in PC-friendly gamepad mode. At least one of the GyroCalibration and SendRumbleLightbar needs to be enabled to switch over to DS4 mode and to use extra features.

Are those gamepads working just fine with PS4 console over BT connection? I don't have any explanation why enabling GyroCalibration would cause massive lag. Faulty gamepad? A bug in calibration routine in DS4Windows?

If disabling gyro helps then is the "Debug_GyroCalibration=FALSE" option or "Debug_ReadGyroData=FALSE" option?
If it is Debug_GyroCalibration=FALSE and Debug_ReadGyroOption=TRUE (well gyro reading dont have any actual meaning without calibration) option then there may be some issue in calibration routine or gamepad is faulty.
If Debug_GyroCalibratino=TRUE and Debug_ReadGyroData=FALSE fixes the issue then there may be a bug in DS4Windows gyro handling (an exception thrown during gyro data calculations?)

something weird that i notice is that when everything is set to false so PC-friendly mode i got a LOT o spikes in latency , i been testing all the settings in long game sessions and eventually all gave me latency i suppose its my pc then

cristianmars22 on 23 Nov 2019

i been testing all the settings in long game sessions and eventually all gave me latency i suppose its my pc then

Have you tested the gamepad in PS4 console? Does it work fine there without any perceived lag in games? Could it be faulty gamepad?

Is the result the same with GyroCalibration=TRUE, SendRumbleLightbarData=FALSE, HidDSetNumInputBuffers=3 options? The idea of enabling GyroCalibration is to force the gamepad to switch over to DS4 mode but BT communication line is used only to read data from the game and not write to gamepad (lightbar, rumble).

mika-n on 23 Nov 2019

i been testing all the settings in long game sessions and eventually all gave me latency i suppose its my pc then

Have you tested the gamepad in PS4 console? Does it work fine there without any perceived lag in games? Could it be faulty gamepad?

Is the result the same with GyroCalibration=TRUE, SendRumbleLightbarData=FALSE, HidDSetNumInputBuffers=3 options? The idea of enabling GyroCalibration is to force the gamepad to switch over to DS4 mode but BT communication line is used only to read data from the game and not write to gamepad (lightbar, rumble).

yes in the console works flawless . i can try rigth now that exact setting let me get back to you in an hour or so

cristianmars22 on 23 Nov 2019

gamepad is practically brand new, 3 months old ,bought pair of them from Sony shop in Bratislava, Slovakia.There are no issues with either of them on console. I just didnt bought original sony adapter ,because of price and because asus behaves better with multiple gamepads
Debug_ReadGyroData =true (others false) result in no latency increase.

Debug_GyroCalibration =true (others false) almost doubles latency, it would go from 4-5 latency standing still to yellow and red 100 depends on position.

It is still better then vanila. if we make vanila latency ex100. then this would be 45% of its latency.
lightbar (+battery) would be arround 30%

IceLancerSR on 23 Nov 2019

gamepad is practically brand new, 3 months old ,bought pair of them from Sony shop in Bratislava, Slovakia.There are no issues with either of them on console. I just didnt bought original sony adapter ,because of price and because asus behaves better with multiple gamepads
Debug_ReadGyroData =true (others false) result in no latency increase.

Debug_GyroCalibration =true (others false) almost doubles latency, it would go from 4-5 latency standing still to yellow and red 100 depends on position.

It is still better then vanila. if we make vanila latency ex100. then this would be 45% of its latency.
lightbar (+battery) would be arround 30%

Only read gyro data on true gave you the best results ?

cristianmars on 23 Nov 2019

hey guys,

i'm also having problems with latency spikes using the latest version of ds4w. already tried several things, but i couldn't find a way to solve it.

i'd like to try out the DS4WindowsDebug_NoDS4Mode.exe. unfortunately i can't find the .exe in the zip file provided by @mika-n (https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems).

the zip only contains DS4WindowsDebug.exe & DS4WindowsDebug.exe.config and the .exe won't even start.

can anyone help me out with this? any other suggestion, like another bt dongle, would also be appreciated.

thank you!

specs:
win 10 x64
ds4windows 1.7.23
Delock USB 2.0 Bluetooth Adapter V4.0
Dualshock 4 v1

shredd0x on 6 Dec 2019

@shredd0x DS4WindowsDebug.exe is updated version of the NoDSMode exe.
turn off 4 things in config.
Maybe "Debug" version should be included in release bundle? I quite enjoyed gaming lag free for some non demanding games (that dont require touchpad etc)

IceLancerSR on 6 Dec 2019

i'd like to try out the DS4WindowsDebug_NoDS4Mode.exe. unfortunately i can't find the .exe in the zip file provided by @mika-n
the zip only contains DS4WindowsDebug.exe & DS4WindowsDebug.exe.config and the .exe won't even start.

xxx_NoDS4Mode.exe is no longer used. The new debug version is DS4WindowsDebug.exe and the xxx.exe.config configuation file can be used to tweak debug options. But, you are correct that the debug version no longer worked because the latest official version and the debug version were out of sync (official version had updated Microsoft.Win32.TaskScheduler.dll library but debug version was still linked to older version).

I just updated the debug version and now it should work with the same libraries from the latest official version. Please re-download the DeviceDetect zip file.
https://github.com/Ryochan7/DS4Windows/wiki/Troubleshooting#detailed-debug-log-file-from-gamepad-connection-problems

mika-n on 6 Dec 2019

@IceLancerSR

turn off 4 things in config.

thank you for your reply. what exactly do you mean by that? what am I supposed to turn off?

@mika-n
thanks for the heads up. i re-downloaded the updated version, but still ain't able to get it working (tried with ds4windows 1.7.23 x64) (´･_･`)

shredd0x on 6 Dec 2019

@IceLancerSR

turn off 4 things in config.
thank you for your reply. what exactly do you mean by that? what am I supposed to turn off?
@mika-n
thanks for the heads up. i re-downloaded the updated version, but still ain't able to get it working (tried with ds4windows 1.7.23 x64) (´･_･`)

Sorry. The new version was actually ahead of the V1.7.23 official version. There is a new version of Tasklibrary file in development version and the debug version already linked against it.

I uploaded yet-another-version of the DeviceDetectDebug.zip file with those up-to-date library DLL files. You may want to install the new debug version into a new folder because it would overwrite Tasklibrary DLL library with a newer version which the official release cannot use yet (until the new version is officially published).

You can turn on/off following DS4WindowsDebug.exe.config options or tweak the number of HID buffers (2 by default, but some people have reported that their BT worked better using 3 or 4 input buffers).

Please note that if you set both Debug_GyroCalibration and Debug_SendRumbleLightbarData as FALSE then the BT gamepad remains in PC-friendly mode (not in true DS4 mode). Gyro and touchpad doesn't work in PC-friendly gamepad mode. Some people have reported that throughput of their BT receiver is better in PC-friendly mode, but the sad fact is that those special DS4 features don't work in that mode in BT.

  <!-- Debug_xx = Debug options to enable/disable/tweak certain features of DS4Windows app -->
  <!--   false = Disabled, true = Enabled. The default value in this file is the normal DS4Windows behaviour -->
  <add key="Debug_GyroCalibration"             value="true" />
  <add key="Debug_SendRumbleLightbarData"      value="true" />
  <add key="Debug_ReadTouchpadData"            value="true" />
  <add key="Debug_ReadGyroData"                value="true" />    
  <add key="Debug_ReadBatteryData"             value="true" />  

  <!-- 0 = Don't set custom number of HID buffers (use Win defaults). >0 Num of incoming HID buffers (default in DS4Windows app is 2 -->
  <add key="Debug_HidDSetNumInputBuffers"      value="2" />

mika-n on 6 Dec 2019

@mika-n
awesome, it's working now. thanks for your effort and support!

shredd0x on 6 Dec 2019

@mika-n
awesome, it's working now. thanks for your effort and support!

Do you mean that the debug version works or that the BT lag is gone now when you use the debug version? If the debug version works better (less lag) then did you tweak DS4WndowsDebug.exe.config options somehow?

mika-n on 7 Dec 2019

@mika-n
I meant that the debug version works. Unfortunately the BT lag still persists. I disabled everything except "Debug_ReadBatteryData" and tried different input buffer values, but that didn't help. The result is pretty much the same as with the vanilla version (sitting directly in front of the bluetooth dongle).

I'm going to try a different BT dongle and hope that I can get rid of this issue.

shredd0x on 9 Dec 2019

Ds4windows: Latency Problem ds4w vs none

All 83 comments

Related issues