I will continue to troubleshoot this and update this thread. So why is this an issue on my PC? My only guess would be some sort of a conflict between currently running applications/games or other hardware. Given that I've had an issue with this DAC+Mumble on my PC across 3 different OSes (7/8.1/10) and different hardware (motherboard/cpu/ram/video replacements), AND that the issue does not occur on a completely different PC, this leads me to believe the DAC itself is fine, Mumble itself is fine, and DAC+Mumble is fine. This is not a Vent vs Mumble jab, just another data point since Ventrilo supports Direct Input as well. On my own PC (the one experiencing the issues), Ventrilo works fine. I don't experience the input-lock symptoms, even if I set LowLevelHooksTimeout to 10000. I've tried this DAC on two other PCs with a fresh Mumble snapshot install. So I've done some more troubleshooting on this. (Longer than the 10 seconds your winhook timeout it set to - which matches your description in the first post of the ticket.). If that's the case, it seems to me that something in our DirectInput polling is taking far too long for some reason. Your LowLevelHooksTimeout set to 10000 gives Mumble 10 seconds to process the event before Windows flags Mumble as "bad" and removes it from the hook chain.ĭoes that add up to what you're seeing? A ~10 second input hang/freeze with winhooks on? So you will have "frozen" keyboard/mouse input for that duration. If the winhook callback is not handled in a timely fashion, the input will not be passed on to other applications, as Mumble needs to process it before it's passed on. When winhooks are enabled, the hook callbacks are processed on the same thread in which we poll DirectInput for state changes. So, when you run with winhooks enabled, it locks up all your input devices on the machine? Not just once, but multiple times?ĭoes it lock them up for around the same amount of time that it takes for your PTT to change state when they're disabled? (The issue you created this ticket for.) If you want, you could try to enable winhooks to be able to work around the problem by suppressing the global shortcut you use for PTT.We install there for a reason, as described above. Try installing a recent Mumble snapshot via the installer on, and install it to its default location.I'd think both of those suggestions are worth a shot: (Change these if your drive letter is different, obviously.) However, Windows only allows this functionality to be enabled if the executable lives in a location the system deems "safe", which is practically only C:\Program Files, or C:\Program Files (x86). Mumble is built with an accessibility flag enabled (uiAccess=true), which allows Mumble to intercept elevated programs, amongst other things. This has vastly different global shortcut behavior than a real installation to C:\Program Files. This would allow you to use Mouse 4 as PTT, and avoid inadvertently going back in browsers, etc. This allows you to bind PTT to Mouse 4, and not let the button press propagate to other applications. If you enable it, you will also gain the ability to suppress global shortcuts. I don't know if you should enable it, but you could try! I've been able to reproduce it on the current stable 1.2.10 version as well as 1.3.0~781. I'm very technically competent so if there is any additional data I can gather, I'll do my best to get it. I've set the LowLevelHooksTimeout setting to 10000. I've had this issue on Windows 7/8.1/10 for months. Pushing the actual Scroll Lock key on the keyboard does not work during this time either. If I'm not transmitting it won't begin, and if I'm in the middle of transmitting it will continue to transmit for up to 10-15sec before it "realizes" the key is no longer pressed.ĭuring one of these episodes I can open settings but when I attempt to re-map the PTT key the interface doesn't register my new key until the same 10-15sec "timeout" occurs. I can continue to click the button and the light goes on and off indicating the Scroll Lock key is actually being pressed. Push to talk work well most of the time, but it will randomly stop recognizing this key input. When I hit the mouse button the Scroll Lock light toggles on the keyboard. I've assigned the Push-to-Talk key in Mumble to be Scroll Lock. I have a Logitech G502 mouse whose extra button is remapped to Scroll Lock.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |