ALSA: usb-audio: allow -EPIPE errors for some v2 messages

The Schiit Hel device does not like to respond to all get_ctl_value_v2() requests for some reason. This used to work in older kernels, but now with more strict checking, this failure causes the device to fail to work.

Cc Jaroslav Kysela <[email protected]>

Cc Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---

This fixes the Shiit Hel device that I have. It used to work on older kernels (a year ago?), but stopped working for some reason and I didn't take the time to track it down. This change fixes the issue for me, but feels wrong for some reason. At least now I can use the device as a headphone driver, much better than the built-in one for my current machine...

If needed, I can take the time to do bisection to track down the real issue here, it might be due to stricter endpoint checking in the USB core, but that feels wrong somehow.

Here's the debugfs USB output for this device, showing the endpoints:

T:  Bus=07 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=30be ProdID=0101 Rev=01.02
S:  Manufacturer=Schiit Audio
S:  Product=Schiit Hel
C:  #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio
E:  Ad=8f(I) Atr=03(Int.) MxPS=   6 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
E:  Ad=05(O) Atr=05(Isoc) MxPS= 104 Ivl=125us
E:  Ad=85(I) Atr=11(Isoc) MxPS=   4 Ivl=1ms
I:  If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
E:  Ad=88(I) Atr=05(Isoc) MxPS= 156 Ivl=125us
I:  If#= 3 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=1ms

Any other suggestions to fix this are welcome.

Quoted 40 lines · Greg Kroah-Hartman

The Schiit Hel device does not like to respond to all get_ctl_value_v2() requests for some reason. This used to work in older kernels, but now with more strict checking, this failure causes the device to fail to work.

Cc Jaroslav Kysela <[email protected]>

Cc Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---

This fixes the Shiit Hel device that I have. It used to work on older kernels (a year ago?), but stopped working for some reason and I didn't take the time to track it down. This change fixes the issue for me, but feels wrong for some reason. At least now I can use the device as a headphone driver, much better than the built-in one for my current machine...

If needed, I can take the time to do bisection to track down the real issue here, it might be due to stricter endpoint checking in the USB core, but that feels wrong somehow.

Here's the debugfs USB output for this device, showing the endpoints:

T:  Bus=07 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=30be ProdID=0101 Rev=01.02
S:  Manufacturer=Schiit Audio
S:  Product=Schiit Hel
C:  #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio
E:  Ad=8f(I) Atr=03(Int.) MxPS=   6 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
E:  Ad=05(O) Atr=05(Isoc) MxPS= 104 Ivl=125us
E:  Ad=85(I) Atr=11(Isoc) MxPS=   4 Ivl=1ms
I:  If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
E:  Ad=88(I) Atr=05(Isoc) MxPS= 156 Ivl=125us
I:  If#= 3 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=1ms

Quoted 1 line

Any other suggestions to fix this are welcome.

Could you show the exact error messages and lsusb -v output? We may paper over only the problematic node instead.

Quoted 42 lines · Takashi Iwai

Quoted 40 lines · Greg Kroah-Hartman

The Schiit Hel device does not like to respond to all get_ctl_value_v2() requests for some reason. This used to work in older kernels, but now with more strict checking, this failure causes the device to fail to work.

Cc Jaroslav Kysela <[email protected]>

Cc Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---

This fixes the Shiit Hel device that I have. It used to work on older kernels (a year ago?), but stopped working for some reason and I didn't take the time to track it down. This change fixes the issue for me, but feels wrong for some reason. At least now I can use the device as a headphone driver, much better than the built-in one for my current machine...

If needed, I can take the time to do bisection to track down the real issue here, it might be due to stricter endpoint checking in the USB core, but that feels wrong somehow.

Here's the debugfs USB output for this device, showing the endpoints:

T:  Bus=07 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=30be ProdID=0101 Rev=01.02
S:  Manufacturer=Schiit Audio
S:  Product=Schiit Hel
C:  #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio
E:  Ad=8f(I) Atr=03(Int.) MxPS=   6 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
E:  Ad=05(O) Atr=05(Isoc) MxPS= 104 Ivl=125us
E:  Ad=85(I) Atr=11(Isoc) MxPS=   4 Ivl=1ms
I:  If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
E:  Ad=88(I) Atr=05(Isoc) MxPS= 156 Ivl=125us
I:  If#= 3 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=1ms

Quoted 4 lines

Quoted 1 line

Any other suggestions to fix this are welcome.

Could you show the exact error messages and lsusb -v output? We may paper over only the problematic node instead.

Sure, here's the dmesg output on 5.15-rc5 when it is turned on:

[Oct11 17:25] usb 7-2.2: new high-speed USB device number 9 using xhci_hcd

[  +0.122422] usb 7-2.2: New USB device found, idVendor=30be, idProduct=0101, bcdDevice= 1.02
[  +0.000009] usb 7-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000002] usb 7-2.2: Product: Schiit Hel
[  +0.000002] usb 7-2.2: Manufacturer: Schiit Audio
[  +0.327172] input: Schiit Audio Schiit Hel as /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:47:00.1/usb7/7-2/7-2.2/7-2.2:1.3/0003:30BE:0101.0009/input/input21
[  +0.055134] hid-generic 0003:30BE:0101.0009: input,hidraw8: USB HID v1.00 Device [Schiit Audio Schiit Hel] on usb-0000:47:00.1-2.2/input3
[  +0.135988] usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[  +0.060647] usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[  +0.065362] usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[  +0.192121] usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1

And here is the 'lsusb -v' output of the device.

Bus 007 Device 009: ID 30be:0101 Schiit Audio Schiit Hel

AudioControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 17
bSourceID 5
bmaControls(0) 0x00000003
Mute Control (read/write)
bmaControls(1) 0x00000000
bmaControls(2) 0x00000000
iFeature 0

Quoted 52 lines · Greg Kroah-Hartman

Quoted 42 lines · Takashi Iwai

Quoted 40 lines · Greg Kroah-Hartman

The Schiit Hel device does not like to respond to all get_ctl_value_v2() requests for some reason. This used to work in older kernels, but now with more strict checking, this failure causes the device to fail to work.

Cc Jaroslav Kysela <[email protected]>

Cc Takashi Iwai <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---

This fixes the Shiit Hel device that I have. It used to work on older kernels (a year ago?), but stopped working for some reason and I didn't take the time to track it down. This change fixes the issue for me, but feels wrong for some reason. At least now I can use the device as a headphone driver, much better than the built-in one for my current machine...

If needed, I can take the time to do bisection to track down the real issue here, it might be due to stricter endpoint checking in the USB core, but that feels wrong somehow.

Here's the debugfs USB output for this device, showing the endpoints:

T:  Bus=07 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=30be ProdID=0101 Rev=01.02
S:  Manufacturer=Schiit Audio
S:  Product=Schiit Hel
C:  #Ifs= 4 Cfg#= 1 Atr=c0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio
E:  Ad=8f(I) Atr=03(Int.) MxPS=   6 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
E:  Ad=05(O) Atr=05(Isoc) MxPS= 104 Ivl=125us
E:  Ad=85(I) Atr=11(Isoc) MxPS=   4 Ivl=1ms
I:  If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
E:  Ad=88(I) Atr=05(Isoc) MxPS= 156 Ivl=125us
I:  If#= 3 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=1ms

Quoted 4 lines

Quoted 1 line

Any other suggestions to fix this are welcome.

Could you show the exact error messages and lsusb -v output? We may paper over only the problematic node instead.

Sure, here's the dmesg output on 5.15-rc5 when it is turned on:

[Oct11 17:25] usb 7-2.2: new high-speed USB device number 9 using xhci_hcd

Quoted 10 lines

[  +0.122422] usb 7-2.2: New USB device found, idVendor=30be, idProduct=0101, bcdDevice= 1.02
[  +0.000009] usb 7-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000002] usb 7-2.2: Product: Schiit Hel
[  +0.000002] usb 7-2.2: Manufacturer: Schiit Audio
[  +0.327172] input: Schiit Audio Schiit Hel as /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:47:00.1/usb7/7-2/7-2.2/7-2.2:1.3/0003:30BE:0101.0009/input/input21
[  +0.055134] hid-generic 0003:30BE:0101.0009: input,hidraw8: USB HID v1.00 Device [Schiit Audio Schiit Hel] on usb-0000:47:00.1-2.2/input3
[  +0.135988] usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[  +0.060647] usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[  +0.065362] usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[  +0.192121] usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1

Thanks. So this happens at the unit 17, and ...

Quoted 4 lines

And here is the 'lsusb -v' output of the device.

Bus 007 Device 009: ID 30be:0101 Schiit Audio Schiit Hel

(snip)

Quoted 11 lines

AudioControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 17
bSourceID 5
bmaControls(0) 0x00000003
Mute Control (read/write)
bmaControls(1) 0x00000000
bmaControls(2) 0x00000000
iFeature 0

... this is the entry.

Could you also post the contents of /proc/asound/card*/usbmixer (only for the corresponding device), too?

Quoted 2 lines · Takashi Iwai

Could you also post the contents of /proc/asound/card*/usbmixer (only for the corresponding device), too?

Sure, here it is:

USB Mixer: usb_id=0x30be0101, ctrlif=0, ctlerr=0
Card: Schiit Audio Schiit Hel at usb-0000:47:00.1-2.2, high speed
Unit: 5

    Control: name="Mic - Input Jack", index=0
    Info: id=5, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 7
    Control: name="Speaker - Output Jack", index=0
    Info: id=7, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 13
    Control: name="PCM Playback Switch", index=0
    Info: id=13, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 17
    Control: name="Mic Capture Switch", index=0
    Info: id=17, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Unit: 18

    Control: name="Clock Source 18 Validity", index=0
    Info: id=18, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 22
    Control: name="Clock Source 22 Validity", index=0
    Info: id=22, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Quoted 25 lines · Greg Kroah-Hartman

Quoted 2 lines · Takashi Iwai

Could you also post the contents of /proc/asound/card*/usbmixer (only for the corresponding device), too?

Sure, here it is:

USB Mixer: usb_id=0x30be0101, ctrlif=0, ctlerr=0
Card: Schiit Audio Schiit Hel at usb-0000:47:00.1-2.2, high speed
Unit: 5

    Control: name="Mic - Input Jack", index=0
    Info: id=5, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 7
    Control: name="Speaker - Output Jack", index=0
    Info: id=7, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 13
    Control: name="PCM Playback Switch", index=0
    Info: id=13, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 17
    Control: name="Mic Capture Switch", index=0
    Info: id=17, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Quoted 8 lines

Unit: 18

    Control: name="Clock Source 18 Validity", index=0
    Info: id=18, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 22
    Control: name="Clock Source 22 Validity", index=0
    Info: id=22, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Hm, I expected more exotic control that failed, but it was Mic Capture Switch, which should be treated normally.

Could you try the patch below? This will still show other warning messages, but it'll forcibly initialize the mixer elements at probe time, and the rest should work.

Once after it's confirmed to work, we may shut up the device warnings with a quirk.

Quoted 39 lines · Takashi Iwai

Quoted 25 lines · Greg Kroah-Hartman

Quoted 2 lines · Takashi Iwai

Could you also post the contents of /proc/asound/card*/usbmixer (only for the corresponding device), too?

Sure, here it is:

USB Mixer: usb_id=0x30be0101, ctrlif=0, ctlerr=0
Card: Schiit Audio Schiit Hel at usb-0000:47:00.1-2.2, high speed
Unit: 5

    Control: name="Mic - Input Jack", index=0
    Info: id=5, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 7
    Control: name="Speaker - Output Jack", index=0
    Info: id=7, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 13
    Control: name="PCM Playback Switch", index=0
    Info: id=13, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 17
    Control: name="Mic Capture Switch", index=0
    Info: id=17, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Quoted 8 lines

Unit: 18

    Control: name="Clock Source 18 Validity", index=0
    Info: id=18, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 22
    Control: name="Clock Source 22 Validity", index=0
    Info: id=22, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Hm, I expected more exotic control that failed, but it was Mic Capture Switch, which should be treated normally.

Quoted 6 lines

Could you try the patch below? This will still show other warning messages, but it'll forcibly initialize the mixer elements at probe time, and the rest should work.

Once after it's confirmed to work, we may shut up the device warnings with a quirk.

Only one warning message shows up, here's the dmesg with this patch applied:

[Oct12 14:39] usb 7-2.2: new high-speed USB device number 10 using xhci_hcd

[  +0.123157] usb 7-2.2: New USB device found, idVendor=30be, idProduct=0101, bcdDevice= 1.02
[  +0.000009] usb 7-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000003] usb 7-2.2: Product: Schiit Hel
[  +0.000002] usb 7-2.2: Manufacturer: Schiit Audio
[  +0.339785] usb 7-2.2: 17:0: failed to get current value for ch 0 (-32)
[  +0.020373] input: Schiit Audio Schiit Hel as /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:47:00.1/usb7/7-2/7-2.2/7-2.2:1.3/0003:30BE:0101.000B/input/input24
[  +0.056868] hid-generic 0003:30BE:0101.000B: input,hidraw6: USB HID v1.00 Device [Schiit Audio Schiit Hel] on usb-0000:47:00.1-2.2/input3

I don't see a "mic capture switch" on this device, but maybe it triggers when I plug a mic into the microphone port, which is currently empty?

Quoted 52 lines · Greg Kroah-Hartman

Quoted 39 lines · Takashi Iwai

Quoted 25 lines · Greg Kroah-Hartman

Quoted 2 lines · Takashi Iwai

Could you also post the contents of /proc/asound/card*/usbmixer (only for the corresponding device), too?

Sure, here it is:

USB Mixer: usb_id=0x30be0101, ctrlif=0, ctlerr=0
Card: Schiit Audio Schiit Hel at usb-0000:47:00.1-2.2, high speed
Unit: 5

    Control: name="Mic - Input Jack", index=0
    Info: id=5, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 7
    Control: name="Speaker - Output Jack", index=0
    Info: id=7, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 13
    Control: name="PCM Playback Switch", index=0
    Info: id=13, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 17
    Control: name="Mic Capture Switch", index=0
    Info: id=17, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Quoted 8 lines

Unit: 18

    Control: name="Clock Source 18 Validity", index=0
    Info: id=18, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 22
    Control: name="Clock Source 22 Validity", index=0
    Info: id=22, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Hm, I expected more exotic control that failed, but it was Mic Capture Switch, which should be treated normally.

Quoted 6 lines

Could you try the patch below? This will still show other warning messages, but it'll forcibly initialize the mixer elements at probe time, and the rest should work.

Once after it's confirmed to work, we may shut up the device warnings with a quirk.

Only one warning message shows up, here's the dmesg with this patch applied:

Quoted 8 lines

[Oct12 14:39] usb 7-2.2: new high-speed USB device number 10 using xhci_hcd

[  +0.123157] usb 7-2.2: New USB device found, idVendor=30be, idProduct=0101, bcdDevice= 1.02
[  +0.000009] usb 7-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000003] usb 7-2.2: Product: Schiit Hel
[  +0.000002] usb 7-2.2: Manufacturer: Schiit Audio
[  +0.339785] usb 7-2.2: 17:0: failed to get current value for ch 0 (-32)
[  +0.020373] input: Schiit Audio Schiit Hel as /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:47:00.1/usb7/7-2/7-2.2/7-2.2:1.3/0003:30BE:0101.000B/input/input24
[  +0.056868] hid-generic 0003:30BE:0101.000B: input,hidraw6: USB HID v1.00 Device [Schiit Audio Schiit Hel] on usb-0000:47:00.1-2.2/input3

OK, then the problem is only about this unit and about the master channel.

Quoted 2 lines

I don't see a "mic capture switch" on this device, but maybe it triggers when I plug a mic into the microphone port, which is currently empty?

This should be persistent and visible; try to run "amixer -c1" (or the different card index for the device).

So far, so good. The only remaining piece is how this -EPIPE error comes up. Is this a protocol stall error or such? Would it be avoided by adding the delay like done for some devices?

With the 5.15-rc kernel, you can pass quirk_flags option to snd-usb-audio module for applying known quirks.
e.g. quirk_flags=0x100 will set the 1msec delay at each control message. Please check whether it makes any difference. The option is an integer array for multiple devices, so if you have multiple USB-audio devices, put at the appropriate position in the array (e.g. quirk_flags=,,0x100 for the 3rd slot).

The quirk bit 0x4000 will shut up the control errors. If the above doesn't fix the warning and the device is working more or less, set this quirk to shut up the warning. It can be set statically in the table at the end in sound/usb/quirks.c.

Quoted 76 lines · Takashi Iwai

Quoted 52 lines · Greg Kroah-Hartman

Quoted 39 lines · Takashi Iwai

Quoted 25 lines · Greg Kroah-Hartman

Quoted 2 lines · Takashi Iwai

Could you also post the contents of /proc/asound/card*/usbmixer (only for the corresponding device), too?

Sure, here it is:

USB Mixer: usb_id=0x30be0101, ctrlif=0, ctlerr=0
Card: Schiit Audio Schiit Hel at usb-0000:47:00.1-2.2, high speed
Unit: 5

    Control: name="Mic - Input Jack", index=0
    Info: id=5, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 7
    Control: name="Speaker - Output Jack", index=0
    Info: id=7, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 13
    Control: name="PCM Playback Switch", index=0
    Info: id=13, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 17
    Control: name="Mic Capture Switch", index=0
    Info: id=17, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Quoted 8 lines

Unit: 18

    Control: name="Clock Source 18 Validity", index=0
    Info: id=18, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 22
    Control: name="Clock Source 22 Validity", index=0
    Info: id=22, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Hm, I expected more exotic control that failed, but it was Mic Capture Switch, which should be treated normally.

Quoted 6 lines

Could you try the patch below? This will still show other warning messages, but it'll forcibly initialize the mixer elements at probe time, and the rest should work.

Once after it's confirmed to work, we may shut up the device warnings with a quirk.

Only one warning message shows up, here's the dmesg with this patch applied:

Quoted 8 lines

[Oct12 14:39] usb 7-2.2: new high-speed USB device number 10 using xhci_hcd

[  +0.123157] usb 7-2.2: New USB device found, idVendor=30be, idProduct=0101, bcdDevice= 1.02
[  +0.000009] usb 7-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000003] usb 7-2.2: Product: Schiit Hel
[  +0.000002] usb 7-2.2: Manufacturer: Schiit Audio
[  +0.339785] usb 7-2.2: 17:0: failed to get current value for ch 0 (-32)
[  +0.020373] input: Schiit Audio Schiit Hel as /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:47:00.1/usb7/7-2/7-2.2/7-2.2:1.3/0003:30BE:0101.000B/input/input24
[  +0.056868] hid-generic 0003:30BE:0101.000B: input,hidraw6: USB HID v1.00 Device [Schiit Audio Schiit Hel] on usb-0000:47:00.1-2.2/input3

OK, then the problem is only about this unit and about the master channel.

Quoted 2 lines

I don't see a "mic capture switch" on this device, but maybe it triggers when I plug a mic into the microphone port, which is currently empty?

This should be persistent and visible; try to run "amixer -c1" (or the different card index for the device).

So far, so good. The only remaining piece is how this -EPIPE error comes up. Is this a protocol stall error or such? Would it be avoided by adding the delay like done for some devices?

Quoted 7 lines

With the 5.15-rc kernel, you can pass quirk_flags option to snd-usb-audio module for applying known quirks.
e.g. quirk_flags=0x100 will set the 1msec delay at each control message. Please check whether it makes any difference. The option is an integer array for multiple devices, so if you have multiple USB-audio devices, put at the appropriate position in the array (e.g. quirk_flags=,,0x100 for the 3rd slot).

This quirk did not work. Well, it caused the error to show up after a delay, but the error is still there.

Quoted 4 lines

The quirk bit 0x4000 will shut up the control errors. If the above doesn't fix the warning and the device is working more or less, set this quirk to shut up the warning. It can be set statically in the table at the end in sound/usb/quirks.c.

This quirk did work in that the error messages are still in the kernel log, but the device seems to work properly now.

Let me send a patch that adds this device to the quirk table.

Quoted 76 lines · Takashi Iwai

Quoted 52 lines · Greg Kroah-Hartman

Quoted 39 lines · Takashi Iwai

Quoted 25 lines · Greg Kroah-Hartman

Quoted 2 lines · Takashi Iwai

Could you also post the contents of /proc/asound/card*/usbmixer (only for the corresponding device), too?

Sure, here it is:

USB Mixer: usb_id=0x30be0101, ctrlif=0, ctlerr=0
Card: Schiit Audio Schiit Hel at usb-0000:47:00.1-2.2, high speed
Unit: 5

    Control: name="Mic - Input Jack", index=0
    Info: id=5, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 7
    Control: name="Speaker - Output Jack", index=0
    Info: id=7, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 13
    Control: name="PCM Playback Switch", index=0
    Info: id=13, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 17
    Control: name="Mic Capture Switch", index=0
    Info: id=17, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Quoted 8 lines

Unit: 18

    Control: name="Clock Source 18 Validity", index=0
    Info: id=18, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 22
    Control: name="Clock Source 22 Validity", index=0
    Info: id=22, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Hm, I expected more exotic control that failed, but it was Mic Capture Switch, which should be treated normally.

Quoted 6 lines

Could you try the patch below? This will still show other warning messages, but it'll forcibly initialize the mixer elements at probe time, and the rest should work.

Once after it's confirmed to work, we may shut up the device warnings with a quirk.

Only one warning message shows up, here's the dmesg with this patch applied:

Quoted 8 lines

[Oct12 14:39] usb 7-2.2: new high-speed USB device number 10 using xhci_hcd

[  +0.123157] usb 7-2.2: New USB device found, idVendor=30be, idProduct=0101, bcdDevice= 1.02
[  +0.000009] usb 7-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000003] usb 7-2.2: Product: Schiit Hel
[  +0.000002] usb 7-2.2: Manufacturer: Schiit Audio
[  +0.339785] usb 7-2.2: 17:0: failed to get current value for ch 0 (-32)
[  +0.020373] input: Schiit Audio Schiit Hel as /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:47:00.1/usb7/7-2/7-2.2/7-2.2:1.3/0003:30BE:0101.000B/input/input24
[  +0.056868] hid-generic 0003:30BE:0101.000B: input,hidraw6: USB HID v1.00 Device [Schiit Audio Schiit Hel] on usb-0000:47:00.1-2.2/input3

OK, then the problem is only about this unit and about the master channel.

Quoted 2 lines

I don't see a "mic capture switch" on this device, but maybe it triggers when I plug a mic into the microphone port, which is currently empty?

This should be persistent and visible; try to run "amixer -c1" (or the different card index for the device).

So far, so good. The only remaining piece is how this -EPIPE error comes up. Is this a protocol stall error or such? Would it be avoided by adding the delay like done for some devices?

Quoted 7 lines

With the 5.15-rc kernel, you can pass quirk_flags option to snd-usb-audio module for applying known quirks.
e.g. quirk_flags=0x100 will set the 1msec delay at each control message. Please check whether it makes any difference. The option is an integer array for multiple devices, so if you have multiple USB-audio devices, put at the appropriate position in the array (e.g. quirk_flags=,,0x100 for the 3rd slot).

This quirk did not work. Well, it caused the error to show up after a delay, but the error is still there.

Quoted 4 lines

The quirk bit 0x4000 will shut up the control errors. If the above doesn't fix the warning and the device is working more or less, set this quirk to shut up the warning. It can be set statically in the table at the end in sound/usb/quirks.c.

This quirk did work in that the error messages are still in the kernel log, but the device seems to work properly now.

Let me send a patch that adds this device to the quirk table.

Quoted 97 lines · Greg Kroah-Hartman

Quoted 76 lines · Takashi Iwai

Quoted 52 lines · Greg Kroah-Hartman

Quoted 39 lines · Takashi Iwai

Quoted 25 lines · Greg Kroah-Hartman

Quoted 2 lines · Takashi Iwai

Could you also post the contents of /proc/asound/card*/usbmixer (only for the corresponding device), too?

Sure, here it is:

USB Mixer: usb_id=0x30be0101, ctrlif=0, ctlerr=0
Card: Schiit Audio Schiit Hel at usb-0000:47:00.1-2.2, high speed
Unit: 5

    Control: name="Mic - Input Jack", index=0
    Info: id=5, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 7
    Control: name="Speaker - Output Jack", index=0
    Info: id=7, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 13
    Control: name="PCM Playback Switch", index=0
    Info: id=13, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 17
    Control: name="Mic Capture Switch", index=0
    Info: id=17, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Quoted 8 lines

Unit: 18

    Control: name="Clock Source 18 Validity", index=0
    Info: id=18, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0
  Unit: 22
    Control: name="Clock Source 22 Validity", index=0
    Info: id=22, control=2, cmask=0x0, channels=1, type="BOOLEAN"
    Volume: min=0, max=1, dBmin=0, dBmax=0

Hm, I expected more exotic control that failed, but it was Mic Capture Switch, which should be treated normally.

Quoted 6 lines

Could you try the patch below? This will still show other warning messages, but it'll forcibly initialize the mixer elements at probe time, and the rest should work.

Once after it's confirmed to work, we may shut up the device warnings with a quirk.

Only one warning message shows up, here's the dmesg with this patch applied:

Quoted 8 lines

[Oct12 14:39] usb 7-2.2: new high-speed USB device number 10 using xhci_hcd

[  +0.123157] usb 7-2.2: New USB device found, idVendor=30be, idProduct=0101, bcdDevice= 1.02
[  +0.000009] usb 7-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000003] usb 7-2.2: Product: Schiit Hel
[  +0.000002] usb 7-2.2: Manufacturer: Schiit Audio
[  +0.339785] usb 7-2.2: 17:0: failed to get current value for ch 0 (-32)
[  +0.020373] input: Schiit Audio Schiit Hel as /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:47:00.1/usb7/7-2/7-2.2/7-2.2:1.3/0003:30BE:0101.000B/input/input24
[  +0.056868] hid-generic 0003:30BE:0101.000B: input,hidraw6: USB HID v1.00 Device [Schiit Audio Schiit Hel] on usb-0000:47:00.1-2.2/input3

OK, then the problem is only about this unit and about the master channel.

Quoted 2 lines

I don't see a "mic capture switch" on this device, but maybe it triggers when I plug a mic into the microphone port, which is currently empty?

This should be persistent and visible; try to run "amixer -c1" (or the different card index for the device).

So far, so good. The only remaining piece is how this -EPIPE error comes up. Is this a protocol stall error or such? Would it be avoided by adding the delay like done for some devices?

Quoted 7 lines

With the 5.15-rc kernel, you can pass quirk_flags option to snd-usb-audio module for applying known quirks.
e.g. quirk_flags=0x100 will set the 1msec delay at each control message. Please check whether it makes any difference. The option is an integer array for multiple devices, so if you have multiple USB-audio devices, put at the appropriate position in the array (e.g. quirk_flags=,,0x100 for the 3rd slot).

This quirk did not work. Well, it caused the error to show up after a delay, but the error is still there.

Quoted 4 lines

The quirk bit 0x4000 will shut up the control errors. If the above doesn't fix the warning and the device is working more or less, set this quirk to shut up the warning. It can be set statically in the table at the end in sound/usb/quirks.c.

This quirk did work in that the error messages are still in the kernel log, but the device seems to work properly now.

Quoted 1 line

Let me send a patch that adds this device to the quirk table.

OK, thanks! The remaining error message should be suppressed with the patch in my previous mail. Or maybe we can add a patch to downgrade the error message to dev_dbg() at first for 5.15, then another one (initializing all controls at first) to 5.16.