Mumble 1.2.11 issue with Objective2 Dac #1977
Comments
|
Please see: #1880 Is this the issue you are seeing? |
|
In particular #1880 (comment) |
|
I followed the same steps that the user posted on that one. And it worked. I found that my DAC also had a HID (saw it when I unplugged it), wrote the hardware IDs of the ones that were left and when I plugged my DAC I found the HID with the different Hardware ID and disabled it. Went in mumble and started like it used to, same with if i unplugged my phone and tested mumble and it worked without issues. I feel so bad because I saw that post and I didn't continue reading down where the person said he/she had a dac. Teaches me to read the full thing. BUT I can add to what he experienced. I have another DAC, with the same symptoms, issue and resolution even if they are different brands. Mine is a O2 Amp/Dac rev b that I just got from massdrop. So i guess there is an issue with the HIDs from the dacs. Thank you so much for you help and sorry for the trouble! |
… 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.
|
Hi @metalmakkusu, 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 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.
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 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
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 I also happen to have an ODAC-revB. Following the process of finding the culprit HID device and disabling it also fixes any issues I had with mumble. Attached is a DxDiag of my system. |
|
What version of Mumble did you use? Both 1.2.x and 1.3.x has a blacklist which should cover the ODAC-revB. I assume that blacklist wasn't effective for your device... Unfortunately, the DxDiag seems to be from after you disabled the HID device. Alternatively, since I only need the vendor and product IDs of the device, you could also look them up in the Device Manager like so:
Thanks! |
|
@mkrautz I have had versions of mumble since 1.2.8 to 1.2.17 and even tried the latest 1.3.0 beta. I ordered it from Head 'n' Hifi. I added a sreenshot of the disabled device.
|
|
@Remyoman Hmmm... The code already tries to blacklist that vendor ID in the last few 1.2.x releases, as well as 1.3.x. Did you have to disable the device in Windows to make it work without freezing in Mumble? |
|
@mkrautz Yes, I was forced to disable it through Windows. I have had the issue get worse over the past months. The problem persisted across a clean install so I decided to look through the (GitHub) issues to look for similar problems. |
|
Hmm, very odd. It should have blacklisted it. Can you run Mumble without the device disabled, and then check your log (%APPDATA%\Mumble\Console.txt) to see if the following message is logged: https://github.com/mumble-voip/mumble/blob/master/src/mumble/GlobalShortcut_win.cpp#L487 ? If not, then our blacklist is broken. |
|
*Edited after double checking log. |
I am having an issue since I started using my Objective2 Amp/DAC (Massdrop ed). When ever I start mumble I have to wait a couple of seconds (about 7-15) to be able to start talking and if I connect/disconnect USB devices (phone, usb drives) mumble hangs also.
This is what I am experiencing in more detail. If my O2 Amp/Dac is not the default playback device, mumble works without issues. I have mumble set to use the default device as output. I can plug and unplug USB devices and i can use my PTT key without issues, mumble will also start normally.
If I have my O2 amp set as the default playback device, the symptoms I encounter start showing up. When I start Mumble, my mouse start lagging behind for about 7 to 10 seconds and then start working normally once Mumble loads the server select screen. If i am in a channel holding down my PTT key while I unplug a USB device and I release the PTT key, mumble will still show as if I was holding down the key for several seconds and I can speak and everyone will hear me normally. If I was not holding it down when I unplug a device and immediately after I pressed my PTT key, mumble will not respond to it immediately and I will have to hold the key down and wait more than 5 seconds to see that it registered my key stroke and then I will be able to speak, people will hear me fine and I will hear them fine also. If I release the key it will hang also and I would be able to speak for a few seconds and it would register as if i was still holding down the key. After a few seconds more everything will come back to normal and I would be able to use my PTT key without issues... unless I decide to unplug my phone or a usb stick and then I will have this issue for the next 7-15 secs.
A list of my devices are
I have the O2, the preamp, mouse and keyboard on USB2 ports. The rest are on my USB3.0 ports. My mother board is an Asus Maximus V Gene z77. I am running win 10 Pro 64bit, my synapse version is 1.18. It only happens when I am using my O2, when I am using my sound card (asus xonar essence stx) i have no issues with this lag/hanging problem with mumble.
The text was updated successfully, but these errors were encountered: