Push to Talk Randomly Not Recognized #1880

ckabalan · 2015-11-10T03:46:48Z

I have a Logitech G502 mouse whose extra button is remapped to Scroll Lock. I've assigned the Push-to-Talk key in Mumble to be Scroll Lock. When I hit the mouse button the Scroll Lock light toggles on the keyboard.

Push to talk work well most of the time, but it will randomly stop recognizing this key input. I can continue to click the button and the light goes on and off indicating the Scroll Lock key is actually being pressed. 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.

During 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. Pushing the actual Scroll Lock key on the keyboard does not work during this time either. Light blinks, no Mumble recognition.

I've had this issue on Windows 7/8.1/10 for months. I've set the LowLevelHooksTimeout setting to 10000. 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 been able to reproduce it on the current stable 1.2.10 version as well as 1.3.0~781.

How can I fix this?

mkrautz · 2015-11-10T07:59:06Z

It could be related to the fact that Scroll Lock can be either on or off. I know we have had people complain about Push-to-Talk-related issues with Caps Lock previously.

Does it also happen if you map any other key than Scroll Lock? Or is Scroll Lock the culprit?

ckabalan · 2015-11-11T19:48:13Z

As a test I changed my PTT key from Scoll Lock to Caps Lock, the issue continued to happen. I changed it from Caps Lock to F12 but haven't had the time for the issue to occur. Will post back with results.

ckabalan · 2015-11-13T05:13:30Z

My PTT button has been set to F12 and I still experience the issue.

Do you have any additional suggestions for remedying or troubleshooting the issue further?

mkrautz · 2015-11-14T19:36:21Z

Sorry, I missed the part about you making a mouse button perform a keypress.

This is unfortunately also known to be flakey, but we'd like to fix it.

Why do you need to bind the mouse button to Scroll Lock, BTW? Is Mumble not able to bind to the mouse button itself? Also, it is possible to bind multiple PTT keys in Mumble, in case you want to be able to use both Scroll Lock and your mouse button for PTT.

Now, we'd like to get to the bottom of why binding a mouse button to a keyboard key via LGS -- I assume that is what you are using?

One thing to try is to disable using HH_KEYBOARD and HH_MOUSE hooks for global shorcuts in Mumble:

winhooks disable registry file: https://drive.google.com/open?id=0Bw-IBZsflR_1dVlPOTl4U3FwTGM
winhooks enable registry file: https://drive.google.com/open?id=0Bw-IBZsflR_1Z0FXbjYtbk5VNFE

ckabalan · 2015-11-14T19:53:49Z

Hi Mikkel, thanks for your response.

Yes Mumble can definitely bind to a mouse button (MOUSE4, etc) no problem. The reason I map it to a keyboard key is because the button will do things like move the browser forward/back at the same time. This of course isn't Mumble's fault, but if I map it to a key that basically does nothing (Scroll Lock, Caps Lock, etc) there aren't many interactions with the foreground application.

Yes, I use LGS (Logitech Gaming Software).

I forgot to mention I am using the portable version of Mumble. My mumble.ini file currently has winhooks=false under the [General] section.

Should I attempt to re-enable this? I seem to recall setting that to false because of some sort of strange USB hang with one of my other USB devices. Basically, randomly, all USB inputs would stop working. This was back on Windows 7, not sure if setting this to true will bring back that hang or not, but it is worth a try.

Would you suggest setting this back to true?

mkrautz · 2015-11-14T20:29:14Z

I don't know if you should enable it, but you could try!

If you enable it, you will also gain the ability to suppress global shortcuts. This allows you to bind PTT to Mouse 4, and not let the button press propagate to other applications. This would allow you to use Mouse 4 as PTT, and avoid inadvertently going back in browsers, etc.

Another thing to be aware of:

You are using Mumble in portable mode. This has vastly different global shortcut behavior than a real installation to C:\Program Files.

Mumble is built with an accessibility flag enabled (uiAccess=true), which allows Mumble to intercept elevated programs, amongst other things.

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). (Change these if your drive letter is different, obviously.)

I'd think both of those suggestions are worth a shot:

Try installing a recent Mumble snapshot via the installer on mumble.info, and install it to its default location. We install there for a reason, as described above. :-)
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.

ckabalan · 2015-11-14T20:55:56Z

Mikkel,

I have installed Mumble using the default path C:\Program Files\Mumble\mumble.exe. I was able to verify my "input lock-up" symptom still exists with winhooks enabled. When I launch Mumble the mouse and keyboard become unresponsive. With winhooks disabled (via the registry change, not the ini file) I do not have this issue. Perhaps this is related to the PTT binding issue, but I doubt it. My understand of this is that the USB Bus hangs until some timeout expires and then continues to function properly.

I will report back as soon as I see the symptoms again.

Thanks again for your continued help troubleshooting this issue.

mkrautz · 2015-11-14T21:15:11Z

So, when you run with winhooks enabled, it locks up all your input devices on the machine? Not just once, but multiple times?

Does 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...)

Technical explanation:

When winhooks are enabled, the hook callbacks are processed on the same thread in which we poll DirectInput for state changes. 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. So you will have "frozen" keyboard/mouse input for that duration. 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.

Does that add up to what you're seeing? A ~10 second input hang/freeze with winhooks on?

If that's the case, it seems to me that something in our DirectInput polling is taking far too long for some reason. (Longer than the 10 seconds your winhook timeout it set to -- which matches your description in the first post of the ticket.).

ckabalan · 2015-11-14T21:23:24Z

I can verify the issue still exists when Mumble is install in Program Files and running in non-portable mode.

I just timed it. I verified LowLevelHooksTimeout was already set to 10000. I closed Mumble, enabled winhooks with the .reg file. Launched Mumble, my mouse immediately became unresponsive when the server list displayed, I counted 10 seconds, and as soon as I said "10" mouse movement was regained.

It looks like your last paragraph is very likely the issue. Are there any logs (or ProcMon) or something I can gather for you to troubleshoot this? I'll do a ProcMon capture in the mean time to see if I can gather anything interesting.

mkrautz · 2015-11-14T21:28:39Z

Unfortunately, I don't think you can get anything useful from ProcMon.

Here's what I suggest, for now. Very low tech:

Look in the Mumble log, %APPDATA%\Mumble\Console.txt, if you're running the system-wide install.
If you're running portable, I suppose it's next to your .exe.

See which devices Mumble recognizes in the GlobalShortcut subsystem. They're listed with DInput GUIDS and human readable names. Anything suspicious in that list? Or only your keyboard and mouse?

Then start unplugging one device after the other, until you find the culprit.

Obviously, if it only lists your keyboard and mouse, it'll be a bit harder. But you should be able to unplug those independently of each other as well.

That's the best I can do for now...

We really need a "warning" in GlobalShortcut if a device takes "too long" to be queried/created...

ckabalan · 2015-11-14T21:38:18Z

Here is the information from Console.txt: https://gist.github.com/SpectralCoding/f0e1fcde0bc75dc3ab5f

I'm not sure how to identify the "System Control" entries, but I began unplugging devices and when I hit my Audio DAC (Aune T1 MK2) the lock-up problem went away. I had gone through some of this in the past and the resolution was the winhooks disable. I guess that only solved the input-lock, but never solved the push-to-talk issue.

How do you recommend I proceed? I'd like to continue using the DAC if possible. Is there a way to somehow ignore this device or skip over it? Some OS-level option I can set to ignore DirectInput for this GUID? I know this is getting a little further away from Mumble, but Mumble is the only app I've seen this be an issue with. I hoping your expertise can help me get a whole solution.

Edit: It looks like the DAC ended up being {d7ea2290-7f38-11e5-8003-444553540000} HID-compliant consumer control device HID-compliant consumer control device:8

mkrautz · 2015-11-14T21:41:30Z

Any idea whatsoever why the DAC would present itself as an input device?

mkrautz · 2015-11-14T21:42:42Z

Or does it?... Did the list in Mumble log change when it was unplugged?

ckabalan · 2015-11-14T21:49:24Z

Heres a new gist of me unplugging the DAC while Mumble is open: https://gist.github.com/SpectralCoding/aabddd3919c90ee10067

Relevant:

<W>2015-11-14 14:47:07.601 WASAPINotificationClient: Device state changed newState= 4 device= "{0.0.0.00000000}.{5e370460-5720-4195-bde0-5397f87cf106}"
<W>2015-11-14 14:47:07.601 WASAPINotificationClient: Default device changed flow= 0 role= 0 device ""
<W>2015-11-14 14:47:07.601 WASAPINotificationClient: Default device changed flow= 0 role= 1 device ""
<W>2015-11-14 14:47:07.601 WASAPINotificationClient: Default device changed flow= 0 role= 2 device ""
<W>2015-11-14 14:47:07.601 WASAPIOutput: GetCurrentPadding failed: hr=0x88890004
<W>2015-11-14 14:47:07.658 Removing device {d7ea2290-7f38-11e5-8003-444553540000}

ckabalan · 2015-11-14T21:56:42Z

Here is a second gist of unplugging and plugging it back in a few times: https://gist.github.com/SpectralCoding/d42682cd67589c0bd01e

Interestingly enough it shows up initially as HID-compliant consumer control device, but then after it is plugged back in it maintains the same GUID but shows up as SA9027 USB Audio. Perhaps there is some issue where the device is being identified as a generic USB HID device until it is re-plugged in?

ckabalan · 2015-11-16T05:17:51Z

So I've done some more troubleshooting on this...

I've tried this DAC on two other PCs with a fresh Mumble snapshot install. I don't experience the input-lock symptoms, even if I set LowLevelHooksTimeout to 10000. Winhooks is on by default (I assume).

On my own PC (the one experiencing the issues), Ventrilo works fine. This is not a Vent vs Mumble jab, just another data point since Ventrilo supports Direct Input as well.

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.

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. I will continue to troubleshoot this and update this thread. If anyone has any suggestions I would be more than glad to hear them.

ckabalan · 2015-11-16T07:23:07Z

I took a different route and decided to reinstall the DAC drivers. That didn't work, but I did notice it installs three devices in Device Manager:

Audio inputs and outputs > SPDIF Interface (2- aune T1mk2 tube usb dac)
Sound, video and game controllers > aune T1mk2 tube usb dac
Human Interface Devices > HID-compliant consumer control device

This reminded me of the lines from Console.txt:

<W>2015-11-14 14:26:03.589 Adding device {d7ea2290-7f38-11e5-8003-444553540000} HID-compliant consumer control device HID-compliant consumer control device:8

Since I established I don't care about whatever "inputs" this DAC has back into the system, I disabled all the HID-compliant consumer control device entries, then re-enabled them one at a time and relaunching Mumble until I found the one that showed up in the Console.txt log. I left that one disabled and over an hour of use none of the issues have re-occurred.

I still don't have any answers as to why this is working, but I'd like a few more days to test before I consider this closed. At this point it looks like a strange presentation on the DAC's side (showing up as a HID). Not sure if Mumble could or should incorporate any code to prevent this from being an issue in the future. I will leave it up to the Dev's to decide if this is an "edge case".

Current state:

Windows 10 64-bit
Mumble -- 1.3.0~797~g74d19f4~snapshot (Portable and Full Install both work)
Aune T1 MK2 USB DAC
HID-compliant consumer control device related to the above Aune DAC is disabled. Other DAC-related Device Manager entries are enabled.
Winhooks unset (assume defaults to enabled)
LowLevelHooksTimeout set to 10000

Will report back within 48 hours if this is resolved or not.

ckabalan · 2015-11-19T03:13:10Z

Reporting back that disabling the HID in Device Manager fixed the issue. I haven't seen the slightest issue in three days.

Mumble devs can choose to close this as "user error" if they want. Otherwise I might suggest investigating a way to prevent this from happening in the future even if it isn't Mumble fault directly. Like I said, Ventrilo does not exhibit the same input-lock that Mumble does.

Thanks again for your troubleshooting skills and helping me get to a solution. I'm definitely more than willing to do testing in the future if you decide to implement some code to work around this. Mumble is by far the best VOIP client out on the market today. The fact that it's OSS and I can host my own unlimited sized server makes it killer over pretty much all other software.

… via DirectInput. We've had reports of various DACs misbehaving, causing Mumble to freeze for a long time when they use global shortcuts. See for example mumble-voip#1880 and mumble-voip#1977. This is not a fix, but it gives users who face this problem a hint if they look in their Mumble log.

mkrautz · 2015-12-20T15:21:26Z

Hi @SpectralCoding,

We'd like to blacklist the HID device in Mumble 1.3.0, and we're trying to collect information on this case, and other cases like it.

If possible, could you provide a DxDiag dump, or a screenshot of the input pane when running DxDiag.exe?

To get a DxDiag dump, run DxDiag.exe and click Save All Information in the lower right corner.

Thanks!

… via DirectInput. We've had reports of various DACs misbehaving, causing Mumble to freeze for a long time when they use global shortcuts. See for example mumble-voip#1880 and mumble-voip#1977. This is not a fix, but it gives users who face this problem a hint if they look in their Mumble log.

… via DirectInput. We've had reports of various DACs misbehaving, causing Mumble to freeze for a long time when they use global shortcuts. See for example #1880 and #1977. This is not a fix, but it gives users who face this problem a hint if they look in their Mumble log.

ckabalan · 2015-12-21T01:22:39Z

Hi @mkrautz,

Below is the relevant information from the "HID-compliant consumer control device" which is disabled on my system:

Device Description:
    HID-compliant consumer control device
Device instance path:
    HID\VID_262A&PID_1168&MI_00\7&19B415D6&0&0000
Hardware Ids:
    HID\VID_262A&PID_1168&REV_0001&MI_00
    HID\VID_262A&PID_1168&MI_00
    HID\VID_262A&UP:000C_U:0001
    HID_DEVICE_SYSTEM_CONSUMER
    HID_DEVICE_UP:000C_U:0001
    HID_DEVICE
Class:
    HIDClass
Class Guid:
    {745a17a0-74d3-11d0-b6fe-00a0c90f57da}

Attached is the DxDiag for my PC with the PC name redacted.

DxDiag.txt

This commit adds a few new fields to the InputDevice struct found in GlobalShortcut_win. We now store the guidProduct in InputDeivce::guidproduct, and extract the vendor ID and product ID from that, if possible. The vendor ID and product ID are stored in InputDevice::product_id and InputDevice::vendor_id. Using these new fields, we blacklist devices in EnumDevicesCB, and reject devices we know to be misbehaving, such as: Device Name: ODAC-revB Vendor/Product ID: 0x262A, 0x1048 mumble-voip#1977 Device Name: Aune T1 MK2 - HID-compliant consumer control device Vendor/Product ID: 0x262A, 0x1168 mumble-voip#1880

This commit adds a few new fields to the InputDevice struct found in GlobalShortcut_win. We now store the guidProduct in InputDeivce::guidproduct, and extract the vendor ID and product ID from that, if possible. The vendor ID and product ID are stored in InputDevice::product_id and InputDevice::vendor_id. Using these new fields, we blacklist devices in EnumDevicesCB, and reject devices we know to be misbehaving, such as: Device Name: ODAC-revB Vendor/Product ID: 0x262A, 0x1048 #1977 Device Name: Aune T1 MK2 - HID-compliant consumer control device Vendor/Product ID: 0x262A, 0x1168 #1880

This commit adds a few new fields to the InputDevice struct found in GlobalShortcut_win. We now store the guidProduct in InputDeivce::guidproduct, and extract the vendor ID and product ID from that, if possible. The vendor ID and product ID are stored in InputDevice::product_id and InputDevice::vendor_id. Using these new fields, we blacklist devices in EnumDevicesCB, and reject devices we know to be misbehaving, such as: Device Name: ODAC-revB Vendor/Product ID: 0x262A, 0x1048 mumble-voip#1977 Device Name: Aune T1 MK2 - HID-compliant consumer control device Vendor/Product ID: 0x262A, 0x1168 mumble-voip#1880 (cherry picked from commit df28734) Conflicts: src/mumble/GlobalShortcut_win.cpp

mkrautz added client windows labels Nov 10, 2015

ckabalan closed this as completed Nov 19, 2015

This was referenced Dec 10, 2015

Mumble Freezes with DAC (not ASIO Freeze) #1546

Closed

Mumble 1.2.11 issue with Objective2 Dac #1977

Closed

mkrautz mentioned this issue Dec 13, 2015

GlobalShortuct_win: warn if a device takes more than 1 second to poll via DirectInput. #1989

Closed

mkrautz mentioned this issue Dec 22, 2015

GlobalShortcut_win: add PID/VID blacklist for misbehaving devices. #2011

Closed

Ingramz mentioned this issue Aug 14, 2017

Mumble is frozen for 10 seconds at startup when ODAC is connected #3224

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Push to Talk Randomly Not Recognized #1880

Push to Talk Randomly Not Recognized #1880

ckabalan commented Nov 10, 2015

mkrautz commented Nov 10, 2015

ckabalan commented Nov 11, 2015

ckabalan commented Nov 13, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

mkrautz commented Nov 14, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

ckabalan commented Nov 14, 2015

ckabalan commented Nov 16, 2015

ckabalan commented Nov 16, 2015

ckabalan commented Nov 19, 2015

mkrautz commented Dec 20, 2015

ckabalan commented Dec 21, 2015

Push to Talk Randomly Not Recognized #1880

Push to Talk Randomly Not Recognized #1880

Comments

ckabalan commented Nov 10, 2015

mkrautz commented Nov 10, 2015

ckabalan commented Nov 11, 2015

ckabalan commented Nov 13, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

mkrautz commented Nov 14, 2015

mkrautz commented Nov 14, 2015

ckabalan commented Nov 14, 2015

ckabalan commented Nov 14, 2015

ckabalan commented Nov 16, 2015

ckabalan commented Nov 16, 2015

ckabalan commented Nov 19, 2015

mkrautz commented Dec 20, 2015

ckabalan commented Dec 21, 2015