You are not logged in.
Hi, I have a problem with my USB headset on Linux.
It produces a tick/pop/electrical-discharge-like sound approximately once every second whenever audio is playing.
I've reproduced it on Arch with the regular, LTS, RT and Zen kernels, as well as on Fedora, CachyOS and Ubuntu LTS, so it does not appear to be specific to my installed Arch setup or kernel.
The same headset does **not** produce the periodic tick when used with native Windows on the same hardware and also on another laptop. I also tested Windows in a VirtualBox VM with USB passthrough, and the tick occurs there too, so the Windows test only works when Windows has direct/native access to the USB device.
I've already tested this directly through ALSA (`speaker-test -D hw:2,0 -c 2 -r 48000 -F S16_LE -t sine -f 1000`), rather than only through PipeWire, and the behavior remains.
I'm trying to determine whether this is a Linux USB/audio driver issue, or something else.
MmdrzaArch% uname -a
Linux MmdrzaArch 7.2.6-arch2-1 #1 SMP PREEMPT_DYNAMIC Mon, 14 Sep 2026 22:41:30 +0000 x86_64 GNU/LinuxMmdrzaArch% lsusb -v -d 0c76:1720
Bus 002 Device 007: ID 0c76:1720 JMTek, LLC. USBFH11
Couldn't open device, some information will be missing
Negotiated speed: Full Speed (12Mbps)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 [unknown]
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0c76 JMTek, LLC.
idProduct 0x1720 USBFH11
bcdDevice 1.00
iManufacturer 1 Solid State System Co.,Ltd.
iProduct 2 USBFH11
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0137
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 10
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x004e
bInCollection 2
baInterfaceNr(0) 1
baInterfaceNr(1) 2
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0201 Microphone
bAssocTerminal 0
bNrChannels 1
wChannelConfig 0x0000
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 17
wTerminalType 0x0301 Speaker
bAssocTerminal 0
bSourceID 49
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 18
wTerminalType 0x0101 USB Streaming
bAssocTerminal 2
bSourceID 33
iTerminal 0
AudioControl Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 5 (SELECTOR_UNIT)
bUnitID 33
bNrInPins 1
baSourceID(0) 50
iSelector 0
AudioControl Interface Descriptor:
bLength 10
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 49
bSourceID 1
bControlSize 1
bmaControls(0) 0x01
Mute Control
bmaControls(1) 0x02
Volume Control
bmaControls(2) 0x02
Volume Control
iFeature 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 50
bSourceID 2
bControlSize 1
bmaControls(0) 0x03
Mute Control
Volume Control
bmaControls(1) 0x00
iFeature 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 1
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x00c0 1x 192 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0001
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 1
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 2
bSubframeSize 3
bBitResolution 24
bSamFreqType 1 Discrete
tSamFreq[ 0] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 13
Transfer Type Isochronous
Synch Type Synchronous
Usage Type Data
wMaxPacketSize 0x0120 1x 288 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 1 Milliseconds
wLockDelay 0x0001
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 18
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize 2
bBitResolution 16
bSamFreqType 1 Discrete
tSamFreq[ 0] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0060 1x 96 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 2
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 0
iInterface 0
AudioStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 18
bDelay 1 frames
wFormatTag 0x0001 PCM
AudioStreaming Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bNrChannels 1
bSubframeSize 3
bBitResolution 24
bSamFreqType 1 Discrete
tSamFreq[ 0] 48000
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0090 1x 144 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
AudioStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x01
Sampling Frequency
bLockDelayUnits 0 Undefined
wLockDelay 0x0000
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 62
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 32MmdrzaArch% cat /proc/asound/card2/stream0
Solid State System Co.,Ltd. USBFH11 at usb-0000:00:1d.0-1.2, full speed : USB Audio
Playback:
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (SYNC)
Rates: 48000
Bits: 16
Channel map: FL FR
Interface 1
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 0x01 (1 OUT) (SYNC)
Rates: 48000
Bits: 24
Channel map: FL FR
Capture:
Status: Stop
Interface 2
Altset 1
Format: S16_LE
Channels: 1
Endpoint: 0x82 (2 IN) (ASYNC)
Rates: 48000
Bits: 16
Channel map: MONO
Interface 2
Altset 2
Format: S24_3LE
Channels: 1
Endpoint: 0x82 (2 IN) (ASYNC)
Rates: 48000
Bits: 24
Channel map: MONOOffline
Is this problem unique to one machine/device combination, or is the device broken on other machines or other USB devices broken on this machine?
Offline
Is this problem unique to one machine/device combination, or is the device broken on other machines or other USB devices broken on this machine?
this device is broken on other machines that have linux, but it works fine if they are running windows, other devices work fine on my PC
Offline
Try to set 'implicit_fb=1' parameter for snd_usb_audio module (Kernel_module#Setting_module_options).
Offline
whether this is a Linux USB/audio driver issue
Windows in a VirtualBox VM with USB passthrough, and the tick occurs there too
whether this is a Linux USB/audio driver issue
Any chance it's actually every other second?
https://wiki.archlinux.org/title/Power_ … utosuspend
Edit: still try dimich's suggestion - that "passthrough" is likely not exactly OVMF…
Last edited by seth (2026-09-23 20:10:18)
Offline
Try to set 'implicit_fb=1' parameter for snd_usb_audio module (Kernel_module#Setting_module_options).
Tried it. After a reboot, /sys/module/snd_usb_audio/parameters/implicit_fb shows Y for the card slots (including the headset's), so it was applied. No change, the tick is the same.
Any chance it's actually every other second?
https://wiki.archlinux.org/title/Power_ … utosuspend
No, I timed it and it's a steady ~1 second interval. I also ruled out autosuspend anyway:
- power/control for the headset was already "on" and runtime_status "active"
- I added a udev rule setting power/autosuspend=-1 for 0c76:1720 and rebooted, same tick
- I also booted with usbcore.autosuspend=-1 system-wide:
MmdrzaArch% cat /proc/cmdline
cat /sys/module/usbcore/parameters/autosuspend
BOOT_IMAGE=/vmlinuz-7.3.0-rc4 root=UUID=4c4a57d6-60cf-4f5e-80bd-b1ebbb8c215a rw loglevel=3 quiet usbcore.autosuspend=-1
-1Note: this boot was on 7.3.0-rc4, so the tick is also present on that kernel, not just 7.2.6.
Still no change with autosuspend off
Fair point about the VirtualBox passthrough, the host kernel still handles the USB controller there, so I'll drop that as evidence. The native Windows test on the same hardware, and on a second laptop, is the reliable comparison.
Also ruled out: unbinding the headset's HID interface, unplugging every other USB device, trying every port. Nothing appears in dmesg during the ticks.
I've also filed this on the kernel Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=222050
Offline
Also ruled out: unbinding the headset's HID interface, unplugging every other USB device, trying every port.
What about unbinding the device at large or testing in the pre-boot system?
Ie. is there an analog artifact that relies on the driver to suppress it?
Offline
What about unbinding the device at large or testing in the pre-boot system?
Ie. is there an analog artifact that relies on the driver to suppress it?
Tried unbinding the whole device (echo '1-1.2' | sudo tee /sys/bus/usb/drivers/usb/unbind), so no driver is attached, and listened with the headphones on and the volume up: complete silence, no tick and no periodic noise. So it's not an analog artifact at idle. The tick only appears while an audio stream is playing.
During boot, I hear a few one-off pops that sound like power-on transients, but nothing periodic. In the BIOS menu itself it is completely silent. So this doesn't look related to the tick.
Offline
Any usbish errors in dmesg/the journal? FWIW an additional arcane module option to try is disabling the low_latency support
sudo modprobe -r snd_usb_audio && sudo modprobe snd_usb_audio low_latency=0but if that would help it's weird that a Windows VM reproduces this, assuming you properly did the passthrough so the device wasn't taken by the kernel driver
Last edited by V1del (Yesterday 08:23:41)
Offline
Any usbish errors in dmesg/the journal?
No. I ran `sudo dmesg -W` (and `journalctl -kf`) while playing audio through the headset for about 5 minutes, with the tick audible. Nothing new was logged after the headset's normal enumeration at boot: no urb errors, disconnects, resets or re-enumeration. I can post the full boot log if it would help.
FWIW an additional arcane module option to try is disabling the low_latency support
lowlatency=0: /sys/module/snd_usb_audio/parameters/lowlatency reads N after reboot, so it applied. Same tick.
but if that would help it's weird that a Windows VM reproduces this, assuming you properly did the passthrough so the device wasn't taken by the kernel driver
I attached the headset with a VirtualBox USB filter. Windows sees the real USBFH11, and the headset no longer appears among Linux's output devices, it still ticked in the VM though.
Offline
i also recorded the ticking with speaker-test -t sine and normal music:
the sine ( mind the volume please )
https://drive.google.com/file/d/174_O5i … sp=sharing
normal music
https://drive.google.com/file/d/1sILpFF … sp=sharing
i also recorded a video with OBS when the sine is playing and the ticks are not present in the video ( mind the volume please) :
https://drive.google.com/file/d/1zHRaIf … sp=sharing
Offline
I ran `sudo dmesg -W` (and `journalctl -kf`) while playing audio
"when attaching the device" might also be interesting - but that tick is periodically on the second.
Any difference between
speaker-test -t sine -f 440 -r 44100
speaker-test -t sine -f 440 -r 48000Offline
"when attaching the device" might also be interesting - but that tick is periodically on the second.
MmdrzaArch% sudo dmesg -W
[ 6318.330772] usb 1-1.2: USB disconnect, device number 3
[ 6321.579040] usb 1-1.2: new full-speed USB device number 9 using ehci-pci
[ 6321.665250] usb 1-1.2: New USB device found, idVendor=0c76, idProduct=1720, bcdDevice= 1.00
[ 6321.666381] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6321.666389] usb 1-1.2: Product: USBFH11
[ 6321.666392] usb 1-1.2: Manufacturer: Solid State System Co.,Ltd.
[ 6321.683310] input: Solid State System Co.,Ltd. USBFH11 as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/1-1.2:1.3/0003:0C76:1720.0007/input/input25
[ 6321.734365] hid-generic 0003:0C76:1720.0007: input,hidraw0: USB HID v1.00 Device [Solid State System Co.,Ltd. USBFH11] on usb-0000:00:1d.0-1.2/input3MmdrzaArch% journalctl -kf
Sep 24 15:57:16 MmdrzaArch kernel: usb 1-1.2: USB disconnect, device number 3
Sep 24 15:57:19 MmdrzaArch kernel: usb 1-1.2: new full-speed USB device number 9 using ehci-pci
Sep 24 15:57:19 MmdrzaArch kernel: usb 1-1.2: New USB device found, idVendor=0c76, idProduct=1720, bcdDevice= 1.00
Sep 24 15:57:19 MmdrzaArch kernel: usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 24 15:57:19 MmdrzaArch kernel: usb 1-1.2: Product: USBFH11
Sep 24 15:57:19 MmdrzaArch kernel: usb 1-1.2: Manufacturer: Solid State System Co.,Ltd.
Sep 24 15:57:19 MmdrzaArch kernel: input: Solid State System Co.,Ltd. USBFH11 as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/1-1.2:1.3/0003:0C76:1720.0007/input/input25
Sep 24 15:57:19 MmdrzaArch kernel: hid-generic 0003:0C76:1720.0007: input,hidraw0: USB HID v1.00 Device [Solid State System Co.,Ltd. USBFH11] on usb-0000:00:1d.0-1.2/input3Any difference between
speaker-test -t sine -f 440 -r 44100 speaker-test -t sine -f 440 -r 48000
tested both of these plus some other random rates, all of them have the same sounding tick at the same ~1 second interval
Last edited by Mmdrza (Yesterday 12:31:50)
Offline
i also recorded the ticking with speaker-test -t sine and normal music
I can clearly hear 1 second ticks in sine wave but not in "normal music" and video.
By the way, intervals between ticks are roughly, in samples: 48730, 49200, 49200, 50630, 47440, 49680, 49010, 50070, 47950. So it's not exactly one second, at least not in DAC's frame of reference. Looks more like programmatical delay.
What does the headset actually look like? Does it have pluggable jack sockets? Mic or headphones autodetection artifact comes to my mind.
Offline
I can clearly hear 1 second ticks in sine wave but not in "normal music" and video.
Not hearing the ticks in the video is expected as I mentioned it's not present when capturing the screen and audio using OBS studio, but the other two sound files were recorded with the headphone's own mic from the sound it was outputting, so you can hear the tick ( it is less noticable in music but I can still hear it, maybe your volume is a bit low? )
By the way, intervals between ticks are roughly, in samples: 48730, 49200, 49200, 50630, 47440, 49680, 49010, 50070, 47950. So it's not exactly one second, at least not in DAC's frame of reference. Looks more like programmatical delay.
What does the headset actually look like? Does it have pluggable jack sockets? Mic or headphones autodetection artifact comes to my mind.
It doesn't have pluggable jack sockets, the headphone itself is a SONA T-RGH304, you can see it here:
https://t-daggerla.com/audio/sona-t-rgh304/
Last edited by Mmdrza (Today 03:14:20)
Offline
https://drive.google.com/file/d/1sILpFF … gVRPp/view doesn't maybe lend itself to expose the artifact because of the "music"…
Can you hear it when muting the mic ?
Do you get it w/ playback from the multi-user.target (2nd link below, don't start any GUI to rule out -most- services polling devices)
usb 1-1.2
Are there any external docks or hubs involved?
Offline
Can you hear it when muting the mic ?
Yes
Do you get it w/ playback from the multi-user.target (2nd link below, don't start any GUI to rule out -most- services polling devices)
Yeah followed your link and went into TTY after a reboot, also muted my mic there too, the ticking is still present when playing the sine
Are there any external docks or hubs involved?
Nope all devices are connected directly to motherboard/front ports ( the headphone is connected to the motherboard port, but i also tested every other port with it )
Last edited by Mmdrza (Today 11:02:58)
Offline
it is less noticable in music but I can still hear it, maybe your volume is a bit low?
Yes, now I can hear it, espessially after applying high-pass filter. However, it doesn't seem as regular as in sine wave. For example, I see two distinct clicks spaced by 547 ms (26270 samples) at the end of the file, followed by another click in 70 ms.
Maybe clicks are somehow related to RGB illumination? Does LEDs behavior differ in linux and windows?
Can you check what HID subdevices the headset registers and what drivers are used for them?
Offline
Maybe clicks are somehow related to RGB illumination? Does LEDs behavior differ in linux and windows?
they're always on, same colors, same behavior even on my phone or with the PC powered off
Can you check what HID subdevices the headset registers and what drivers are used for them?
Here's what the headset registers, straight from the system:
lsusb -t (headset is Dev 003 / If 0–3):
|__ Port 002: Dev 003, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 002: Dev 003, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 002: Dev 003, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 002: Dev 003, If 3, Class=Human Interface Device, Driver=usbhid, 12M/proc/bus/input/devices (only entry matching the headset):
I: Bus=0003 Vendor=0c76 Product=1720 Version=0100
N: Name="Solid State System Co.,Ltd. USBFH11"
P: Phys=usb-0000:00:1d.0-1.2/input3
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/1-1.2:1.3/0003:0C76:1720.0001/input/input2
U: Uniq=
H: Handlers=kbd event2
B: PROP=0
B: EV=13
B: KEY=7800000000 e000000000000 0
B: MSC=10hidraw mapping (only entry matching 0c76:1720):
== /sys/class/hidraw/hidraw0 ==
KERNEL=="hidraw0"
KERNELS=="0003:0C76:1720.0001"
KERNELS=="1-1.2:1.3"
KERNELS=="1-1.2"
ATTRS{idProduct}=="1720"That's every HID-related entry the system has for this device — of its 4 interfaces, only one (If 3) is HID, and it creates exactly one input node and one hidraw node, nothing more.
And the per-interface driver bindings for the headset (0c76:1720, all four of its interfaces):
/sys/bus/usb/devices/1-1.2:1.0 -> snd-usb-audio
/sys/bus/usb/devices/1-1.2:1.1 -> snd-usb-audio
/sys/bus/usb/devices/1-1.2:1.2 -> snd-usb-audio
/sys/bus/usb/devices/1-1.2:1.3 -> usbhidLast edited by Mmdrza (Today 16:51:48)
Offline
From your kernel big
Host controller is EHCI only (ASRock H61M-VG3 chipset has no xHCI). Historical kernel bugs (e.g. bugzilla #6709, #9230) describe a similar class of periodic clicking on USB audio devices tied to isochronous transfer scheduling/timing under EHCI, and a 2013 kernel commit note describes the EHCI periodic scheduler's split-transaction handling as fragile enough that a fix for one bug there previously caused audible playback regressions on other devices. I'm not asserting this is the same root cause — just flagging it as a possibly related historical pattern in case it's useful context.
Do you have access to an xhci system that you could test this on?
Offline
Do you have access to an xhci system that you could test this on?
Not currently in my possession no but i'll see if i can get one and report back
Offline