Mouse stop responding when using microphone on a Sennheiser GP350 USB

[Exaltia]

Hello, Since the start, each time i activate the microphone on my headset, the mouse stop responding.

The problem occurs in any application that want to use the microphone. I've tested chromium, firefox, and arecord. Each time the microphone is used, the mouse stop responding immediatly. As soon as i stop using the microphone, the mouse come back to life without any other problem

The mouse stay powered, the leds on it stay powered on, no dimming, no flickering I also tried to connect the mouse to an external self powered usb hub to be sure and the matter is the same.

The headset is connected to the external usb hub too. I tried to disable the button wich was detected by X11 as an input keyboard, without any difference. The first mouse tested is a razer naga trinity. The second mouse tested with the same matter is a logitech G502. However, the problem doesn't occur with a Logitech M185

To reproduce

• type command arecord -D plughw:1 --duration=10 to record something on the terminal.
• Try to move the mouse and see it not moving anymore the cursor or responding to clicks

Expected behaviour Use the microphone will still using the mouse

Actual behaviour The mouse stop responding as soon as the microphone is activated to record something and come back to life when the microphone is not used anymore, or unplugged

System Link to raspinfo output : http://paste.debian.net/1124592

I can give two more raspinfo with the two other mouse if needed.

[P33M]

What version of VLI USB controller firmware are you using? Install the package rpi-eeprom sudo apt install rpi-eeprom and run sudo vl805.

[Exaltia]

Hello, Here is the result from the command : VL805 FW version: 000137ab

[P33M]

Does the behaviour change if you run the command sudo setpci -s 01:00.0 0xd4.B=0x41?

[Exaltia]

Unfortunaly, no, the behaviour is still the same

[P33M]

Hm. Please post a full sudo lsusb -v with the headset, M185 plugged in and the G502 plugged in.

[Exaltia]

Do you want one lsbusb -v per mouse or one with all the mouse connected at the same time?

[P33M]

To avoid repetition of most of the output, do a single one with all the devices connected.

[Exaltia]

While doing the command i had all those errors :

can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable can't get device qualifier: Resource temporarily unavailable can't get debug descriptor: Resource temporarily unavailable

Here is the result of sudo lsusb -v : http://paste.debian.net/1125004/

[P33M]

There's a lot of HID endpoints there with bInterval set to 1 - i.e. poll every millisecond. This would be a problem if the attached hub was single-TT, and you had one of these mice on the same hub as the headset, but the genesys USB2.0 hub has a TT per port. That configuration should have no issues when the mouse is in use at the same time as the headphones.

Interestingly, the logitech wireless receiver has a polling bInterval of 2, and that one works.

A thought occurs - what happens if you add usbhid.mousepoll=0 as a parameter in /boot/cmdline.txt (and reboot)?

[JamesH65]

Isn't that a cmdline.txt parameter?

[P33M]

Yep - crossed wires.

[Exaltia]

I've added this parameter in the cmdline.txt parameter and rebooted. It changed the default mouse speed to something quicker but the original behavior is still there with the G502 and the razer naga trinity. Still works fine with the M185.

P.S you are talking about a genesys USB 2.0 hub. but the headset and all other mouses were all attached to my external usb hub wich is connected to a USB 3.0 (Aka USB 3.1 GEN 1 with the new naming scheme) port on the raspberry when i had done the sudo lsusb -v Or maybe i didn't understood correctly your words :)

[Exaltia]

I fiddled a bit more with this behavior. I was able to obtain a working state, but with the G502 mouse only, by doing the following actions. Plugging the usb pheriphal in this sequence : 1 : Sennheiser GP 350 2 : Logitech keyboard G810 3 : Logitech G502 Mouse At this state , if i use the microphone, i still loose the mouse 4 : unplugging the keyboard 5 : pluggin it back at the same usb port Then it works If i do exactly the same thing with the razer mouse instead of the G502 i loose the mouse at step 3 but i loose the keyboard after step 5 instead of the mouse but it still doesn't work correctly.

No logs anywhere (daemon.log, kern.log, syslog) reports a problem with those devices. I tried this with all peripherals connected on the raspberry or all pheripherals connected on the external usb hub and the result is always the same and reproductible

i tested those devices on a live debian on an X86_64 architecture and kernel and it works fine with the razer mouse from the start

[P33M]

Can you capture an xhci trace?

sudo -s
cd /sys/kernel/debug/tracing
echo 1 > events/xhci-hcd/enable
[Plug device(s) in]
[Run the command that doesn't work as expected]
[Disconnect device]
cat trace > /home/pi/some-sensible-filename.txt

And upload the trace file to pastebin? To clear the trace buffer, run
echo > sys/kernel/debug/tracing/trace.

[Exaltia]

Here is the trace. https://slexy.org/view/s20ORq49KK

[P33M]

There's a newer firmware available that is likely to solve your issue - see https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=260879

Audio devices use isochronous streams so while the update was specifically targeted at webcams, your microphone should get fixed.

Also, the trace is no longer available. Pastebin retains stuff for a bit longer.