On Thu, Oct 14, 2021 at 01:38:32PM +0200, Takashi Iwai wrote:
On Thu, 14 Oct 2021 12:56:26 +0200, Greg Kroah-Hartman wrote:
On Tue, Oct 12, 2021 at 03:24:04PM +0200, Takashi Iwai wrote:
On Tue, 12 Oct 2021 14:41:44 +0200, Greg Kroah-Hartman wrote:
On Tue, Oct 12, 2021 at 09:35:16AM +0200, Takashi Iwai wrote:
On Mon, 11 Oct 2021 19:23:05 +0200, Greg Kroah-Hartman wrote:
On Mon, Oct 11, 2021 at 06:07:01PM +0200, Takashi Iwai wrote: > 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
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.
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
OK, then the problem is only about this unit and about the master channel.
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).
This quirk did not work. Well, it caused the error to show up after a delay, but the error is still there.
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.
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.
Either works for me. If you want me to test anything out with this device, just let me know!
thanks,
greg k-h