c++ - DirectInput8 EnumDevices 有时慢得令人痛苦

Question

有时(在大约 50% 的运行中)，EnumDevices 需要 5-10 秒才能返回。通常它几乎是即时的。我找不到关于此类行为的任何其他报告。

当事情变得如此缓慢时，可以通过观察 stdout 来分析 :) 这:

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;
}

似乎通过枚举设备卡在一个随机点 - 有时会在调用回调之前，有时会在调用回调之后，有时会在最后一次调用回调之后。

这显然是一段简化的代码；我实际上使用的是 OIS 输入库 ( http://sourceforge.net/projects/wgois/ )，因此对于上下文，请在此处查看完整源代码:

http://wgois.svn.sourceforge.net/viewvc/wgois/ois/trunk/src/win32/Win32InputManager.cpp?revision=39&view=markup

虽然那里似乎没有任何特别的果味，但可能是它们初始化中的某些东西可能是原因 - 我对 DI8 的了解还不够多，无法发现它。

任何关于为什么它会这么慢的想法将不胜感激!

编辑:

我已经设法在 etl 跟踪文件中发现了挂起，并在 Windows 性能分析器中对其进行了分析。看起来 EnumDevices 最终调用了 DInput8.dll!fGetProductStringFromDevice，后者调用了 HIDUSB.SYS!HumCallUSB，后者调用了 KeWaitForSingleObject 并等待。 10 次中有 9 次(从字面上看 - 跟踪中有 10 个样本)返回速度非常快(每次 324us)，准备调用堆栈包含 usbport.sys!USBPORT_Core_iCompleteDoneTransfer 后跟 HIDUSB.SYS !HumCallUsbComplete，看起来很正常。

但是 10 次中有 1 次，这几乎需要 5 秒才能返回。在准备调用堆栈上是 ntkrnlmp.exe!KiTimerExpiration 而不是 HIDUSB.SYS 函数。我猜所有这些都表明 HIDUSB.SYS 驱动程序正在以 5 秒的超时异步查询设备，有时它会失败并达到此超时。

我不知道此故障是否与任何特定设备相关(我确实有一些 USB HID)或者它是否是随机的 - 很难测试，因为它并不总是发生。同样，任何人都可以提供给我的任何信息都将不胜感激，但鉴于 DirectInput 所处的奇怪情况，我不希望微软尽快修复此问题!

也许我只需要更早地开始异步初始化输入，并接受有时在用户输入发生之前会有 5 秒的延迟。

Answer 1

我也遇到过这个问题，主要是作为最终用户，但多年来它一直让我恼火。直到我在一个开源项目中遇到它并能够调试它，我才意识到这是这个问题。

原来这是我的 USB 耳机 DAC(Massdrop 的目标 DAC)，它安装驱动程序:wdma_usb.inf_amd64_134cb113911feba4\wdma_usb.inf 用于设备实例 ID USB\VID_262A&PID_1048&MI_01\7&F217D4F&0&0001 然后在声音、视频和游戏 Controller 下的设备管理器中显示为:ODAC-revB USB DAC，在人机接口(interface)设备下显示为:USB 输入设备和 HID 兼容的消费者控制设备。

我不知道 HID 条目的作用但是......当它们被启用并且这个 DAC 被设置为音频输出设备时，IDirectInput8_CreateDevice 和 EnumDevices 都非常慢。禁用“USB 输入设备”条目似乎不会造成任何负面影响，并且完全解决了我的问题。

将 DAC 的音频输出更改为其他任何内容也奇怪地解决了这个问题。

这太糟糕了，以至于游戏 handle 配置对话框 joy.cpl 无法使用、挂起并最终崩溃。

我只是希望这只是一个评论，但我没有足够的代表，这几乎是互联网上唯一描述这个问题的地方，但希望有一天这对其他人有帮助!