Following a discussion on Mastodon about an audio device not working with ALSA (1), and seeing the driver actually had some code mentioning the PID & VID of the device in cards.c (13e5:0001), I searched why the IDs disappeared from modinfo since 5.7… I finally traced it back to commit 5436f59 (ALSA: usb-audio: Move device rename and profile quirks to an internal table) which moved it out of the quirks table and so also out of the list of supported IDs. And since this device is vendor-specific, it's not picked up by the class catch-all. I suppose it's also the case for other devices in the usb_audio_names list. 1. (in French) https://diaspodon.fr/@AugierLe42e/108191825607314746
So this implies that your device isn't really declared as USB audio class compliant, and the quirk was rather for allowing the probe, not only the device rename. Could you give the lsusb -v output for the corresponding device? And/or, at best with alsa-info.sh output (run with --no-upload option and attach the output to Bugzilla).
BTW, I'll be off from tomorrow, so the further reply will be delayed.
> So this implies that your device isn't really declared as USB audio class > compliant, and the quirk was rather for allowing the probe, not only the > device rename. That's what I suspect. > Could you give the lsusb -v output The device is not mine but looking for it online it seemed to be the case: https://www.winehq.org/pipermail/wine-devel/2007-May/056566.html My friend will check tonight on his model. And as I said, it's likely also the case for other devices on this list.
Created attachment 300810 [details] lsusb -v and other various logs Various logs provided by Augier who owns the device.
So yeah, vendor-specific: > # lsusb -v > > Bus 001 Device 005: ID 13e5:0001 Rane SL-1 > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 255 Vendor Specific Subclass > bDeviceProtocol 255 Vendor Specific Protocol > bMaxPacketSize0 32 > idVendor 0x13e5 Rane > idProduct 0x0001 SL-1 > bcdDevice 1.00 > iManufacturer 1 Serato > iProduct 2 Serato Scratch LIVE(c)2004 > iSerial 0
He also confirmed the card is detected fine with a: > echo "13e5 0001" >> /sys/bus/usb/drivers/snd-usb-audio/new_id Although he did have an error trying to configure it in Mixxx (couldn't determine sampling frequency or something alike), but maybe that was because he didn't plug all the equipment with it.
(and it used to work on older kernels: https://mixxx.discourse.group/t/rane-sl-1-and-linux-manjaro/23571/5 https://mixxx.discourse.group/t/rane-sl-1/9979/3 )
OK, thanks. Could you try the patch below?
Created attachment 300918 [details] Test fix patch
It seems the patch works. He now has one of 2 inputs and one if 2 outputs working (not more than with the new_id trick though) and he gets this in dmesg: > usb 1-9: new full-speed USB device number 7 using xhci_hcd > usb 1-9: New USB device found, idVendor=13e5, idProduct=0001, bcdDevice= 1.00 > usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 1-9: Product: Serato Scratch LIVE(c)2004 > usb 1-9: Manufacturer: Serato > usb 1-9: Found post-registration device assignment: 13e50001:02 > usb 1-9: Found post-registration device assignment: 13e50001:05 With the new_id trick he also had this: > usb 1-9: new full-speed USB device number 5 using xhci_hcd > usb 1-9: New USB device found, idVendor=13e5, idProduct=0001, bcdDevice= 1.00 > usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 1-9: Product: Serato Scratch LIVE(c)2004 > usb 1-9: Manufacturer: Serato > usb 1-9: 4:0: cannot get min/max values for control 2 (id 4) > usb 1-9: 9:3: cannot get min/max values for control 2 (id 9) > usb 1-9: cannot find UAC_HEADER > snd-usb-audio: probe of 1-9:1.8 failed with error -22 > usb 1-9: 4:0: cannot get min/max values for control 2 (id 4) > usb 1-9: 9:3: cannot get min/max values for control 2 (id 9) > usb 1-9: 4:0: cannot get min/max values for control 2 (id 4) > usb 1-9: 9:3: cannot get min/max values for control 2 (id 9) By the way, I only searched for the first few ones but it seems other devices in the rename list will need patching: > 03f0:0269 > > https://github.com/linuxhw/LsUSB/blob/ce17f82eb772b89e87bbd6b45202932bf64bb2cc/Notebook/Hewlett-Packard/ZBook/ZBook%2017%20G5/3565F01BE89A/FEDORA-31/5.3.15-300.FC31.X86_64/X86_64/DDDCE22B3D#L420 > (Defined at Interface level) > Audio:Control Device > > 0414:a000 > > https://github.com/linuxhw/LsUSB/blob/37e7f7a22cd55f1499a91e96af74a5fe02d02a0d/Desktop/Gigabyte%20Technology/TRX40/TRX40%20AORUS%20MASTER/503BC2A265EA/UBUNTU-18.04/4.15.0-88-GENERIC/X86_64/785E23D535#L3165 > 239 Miscellaneous Device:2 ?:1 Interface Association >Audio:Control Device
(In reply to François Revol from comment #10) > It seems the patch works. He now has one of 2 inputs and one if 2 outputs > working (not more than with the new_id trick though) and he gets this in > dmesg: Good to hear. It's already on the way to mainline. > By the way, I only searched for the first few ones but it seems other > devices in the rename list will need patching: > > > 03f0:0269 > > > > > https://github.com/linuxhw/LsUSB/blob/ce17f82eb772b89e87bbd6b45202932bf64bb2cc/Notebook/Hewlett-Packard/ZBook/ZBook%2017%20G5/3565F01BE89A/FEDORA-31/5.3.15-300.FC31.X86_64/X86_64/DDDCE22B3D#L420 > > (Defined at Interface level) > > Audio:Control Device This is the standard audio, so it needs no quirk unlike yours (that has Vendor Specific interface) for probing. The entry was purely for renaming. > > > > 0414:a000 > > > > > https://github.com/linuxhw/LsUSB/blob/37e7f7a22cd55f1499a91e96af74a5fe02d02a0d/Desktop/Gigabyte%20Technology/TRX40/TRX40%20AORUS%20MASTER/503BC2A265EA/UBUNTU-18.04/4.15.0-88-GENERIC/X86_64/785E23D535#L3165 > > 239 Miscellaneous Device:2 ?:1 Interface Association > >Audio:Control Device Ditto.
Thanks!
Hello! I am the user with the Rane mentionned in that thread. Just making a quick follow-up here. The fix worked and the Rane is now correctly detected again but I'm still having issues as not all its inputs ans outputs are correctly detected by ALSA. But since this is an old but (it also reproduces on an Ubuntu 18.04 with a 4.15.0 kernel), I will open a new ticket. Thank you for your time.