DirectInput8 EnumDevices有时会非常缓慢 [英] DirectInput8 EnumDevices sometimes painfully slow
问题描述
有时(大约运行50％)，EnumDevices需要5到10秒才能返回.通常，它几乎是即时的.我找不到其他有关这种行为的报告.
Sometimes (in about 50% of runs), EnumDevices takes 5-10 seconds to return. Normally it is almost instant. I couldn't find any other reports of this kind of behaviour.
当事情进展缓慢时，可以通过看stdout来进行分析:)这:
When things are this slow, it's ok to profile by watching stdout :) This:
std::cout << "A";
directInput8Interface->EnumDevices(DI8DEVCLASS_GAMECTRL, MyCallback, NULL, DIEDFL_ATTACHEDONLY);
std::cout << "C";
...
BOOL CALLBACK MyCallback(LPCDIDEVICEINSTANCE, LPVOID)
{
std::cout << "B";
return DIENUM_CONTINUE;
}
似乎通过枚举设备挂在了一个随机点上-有时会在根本没有调用回调之前，有时是在调用两次之后，有时甚至是在最后一次调用它之后.
Seems to hang at a random point through enumerating devices - sometimes it'll be before the callback is called at all, sometimes after a couple, and sometimes it will be after the last call to it.
这显然是简化的代码块；我实际上在使用OIS输入库( http://sourceforge.net/projects/wgois/)，因此，有关上下文，请在此处查看完整的源代码:
This is clearly a simplified chunk of code; I'm actually using the OIS input library ( http://sourceforge.net/projects/wgois/ ), so for context, please see the full source here:
尽管那里似乎没有什么特别富有成果的东西，但可能是它们初始化过程中的某些原因-我对DI8知之甚少.
There doesn't seem to be anything particularly fruity going on there though, but possibly something in their initialisation could be the cause - I don't know enough about DI8 to spot it.
任何关于它为何如此缓慢的想法都将不胜感激！
Any ideas about why it could be so slow will be greatly appreciated!
我设法抓住了etl跟踪文件中的问题，并在Windows Performance Analyzer中对其进行了分析.看起来 EnumDevices 最终调用了 DInput8.dll！fGetProductStringFromDevice ，后者调用了 HIDUSB.SYS！HumCallUSB ，后者调用了 KeWaitForSingleObject 并等待.10次中有9次(从字面上看-跟踪中有10个样本)会非常快地返回(每个样本324us)，准备好的调用堆栈包含 usbport.sys！USBPORT_Core_iCompleteDoneTransfer 后跟 HIDUSB.SYS！HumCallUsbComplete ，看起来很正常.
I've managed to catch the hang in an etl trace file and analysed it in Windows Performance Analyzer. It looks like EnumDevices eventually calls through to DInput8.dll!fGetProductStringFromDevice, which calls HIDUSB.SYS!HumCallUSB, which calls KeWaitForSingleObject and waits. 9 times out of 10 (literally - there are 10 samples in the trace) this returns very quickly (324us each), with the readying callstack containing usbport.sys!USBPORT_Core_iCompleteDoneTransfer followed by HIDUSB.SYS!HumCallUsbComplete, which looks quite normal.
但是十分之一的时间，这几乎需要5秒钟才能返回.在准备好的调用堆栈上是 ntkrnlmp.exe！KiTimerExpiration 而不是 HIDUSB.SYS 函数.我想这一切都表明HIDUSB.SYS驱动程序正在以5秒的超时异步查询设备，有时它会失败并达到此超时.
But 1 time in 10, this takes almost exactly 5 seconds to return. On the readying callstack is ntkrnlmp.exe!KiTimerExpiration instead of the HIDUSB.SYS function. I guess all this indicates that the HIDUSB.SYS driver is querying devices asynchronously with a timeout of 5 seconds, and sometimes it fails and hits this timeout.
我不知道该故障是否与任何一个设备有关(我确实有几个USB HID)还是随机的-很难测试，因为它并不总是发生.再说一次，任何人都可以提供给我的信息将不胜感激，尽管鉴于DirectInput处于一种奇怪的境地，我不希望微软尽快解决此问题！
I don't know whether this failure is associated with any one device in particular (I do have a few USB HIDs) or if it's random - it's hard to test because it doesn't always happen. Again, any information anyone can give me will be appreciated, though I don't hold out any hope for Microsoft fixing this any time soon given the odd situation DirectInput is in!
也许我只需要更早地开始异步初始化输入，并接受有时可能会有5秒钟的延迟才可以进行用户输入.
Perhaps I'll just have to start initialising input earlier, asynchronously, and accept that sometimes there'll be a 5 second delay before user input can happen.
推荐答案
我也经常遇到这种情况，主要是作为最终用户，但多年来一直困扰着我.直到我在一个开源项目中遇到了这个问题并能够对其进行调试，我才意识到这是一个问题.
I was running into this too, largely as an end user, but it's been annoying the hell out of me for years. I didn't realize it was this issue until I ran into it on an open source project and was able to debug it.
原来是我的USB耳机DAC(Massdrop的Objective DAC)，它安装了驱动程序: wdma_usb.inf_amd64_134cb113911feba4 \ wdma_usb.inf 作为设备实例ID USB \ VID_262A& PID_1048&; MI_01 \ 7& F217D4F& 0& 0& 0001 ，然后在设备管理器中的声音，视频和游戏控制器下显示为 ODAC-revB USB DAC ，在人机接口设备下显示为: USB输入设备和符合HID的消费者控制设备.
Turns out it was my USB Headphone DAC (The Objective DAC from Massdrop), it installs the driver: wdma_usb.inf_amd64_134cb113911feba4\wdma_usb.inf for Device Instance ID USB\VID_262A&PID_1048&MI_01\7&F217D4F&0&0001 and then shows up in Device Manager under Sound, video and game controllers as: ODAC-revB USB DAC and, under Human Interface Devices as: USB Input Device and HID-compliant consumer control device.
我不知道HID条目的作用，但是...当启用它们并将此DAC设置为音频输出设备时，IDirectInput8_CreateDevice和EnumDevices都非常缓慢.禁用"USB输入设备"条目似乎不会造成负面影响，并完全解决了我的问题.
I have no idea what the HID entries do but... When they are enabled and this DAC is set as the Audio Output device both IDirectInput8_CreateDevice and EnumDevices are painfully slow. Disabling the "USB Input Device" entry seems to cause no negative effects and completely solves my issue.
将DAC的音频输出更改为其他任何内容也很奇怪地解决了这个问题.
Changing the Audio output from the DAC to anything else also weirdly solved the issue.
这太糟糕了，以至于使游戏手柄配置"对话框joy.cpl无法使用，挂起并最终崩溃.
This was so bad that it made the Gamepad Configuration dialog joy.cpl unusable, hanging and eventually crashing.
我希望这只是一个评论，但我对此没有足够的代表，这几乎是互联网上唯一描述此问题的地方，但希望有一天能对其他人有所帮助！
I was wanting this to just be a comment but I don't have enough rep for it, and this is pretty much the only place on the internet that describes this problem though so hopefully this helps someone else one day!
这篇关于DirectInput8 EnumDevices有时会非常缓慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
