Summary ======= This issue is a continuation of https://bugzilla.kernel.org/show_bug.cgi?id=215887 where the Rane SL-1 wasn't detected anymore following a refactor in quirks-table.h. This bug seems to be older since it reproduces on an Ubuntu 18.04 with 4.15.0 kernel and Fedora 36 with 5.17.12 even though it reproduces slightly differently on those two systems. The Rane SL-1 is a fairly old soundcard with two stereo inputs (audio RCA), 2 stereo outputs (audio RCA) and a preamp phono input (6.3mm jack). The problem =========== When I plug the SL-1 in, I can only detect 2 of the 4 inputs/outputs on ALSA (using pavucontrol). On Fedora 36 (kernel 5.17.12) I only detect the 2 outputs. On Ubuntu studio 18.04 (kernel 4.15.0), I only detect 1 input and 1 output. I also have trouble seing the IOs under Mixxx, JACK (qjackctl) and Pipewire (qpwgraph) Some more context ================= I found evidence on internet that this soundcard worked seemlessly for some people at somewhere between 2009 and 2011[1][2][3]. At least the 4 RCA inputs/outputs. I even found a patch submitted to ALSA dating back to 2009 for enabling the preamp phono input[4] (I don't know if it was ever accepted). I am an experienced Linux user and a developer so I'm definitly willing to help. I just lack the C, ALSA and kernel knowledge to debug this myself. Can you help me on this? [1]: http://www.pogo.org.uk/~mark/linuxdj/ [2]: https://mixxx.discourse.group/t/rane-sl-1/9979/3 [3]: https://github.com/lpil/linux-audio-interface-compatibility/blob/master/README.md#rane-sl-1 [4]: https://mailman.alsa-project.org/pipermail/alsa-devel/2009-January/013856.html
Could you show `aplay -D hw:1 --dump-hw-params /dev/zero` ? Replace 1 with the appropriate ALSA card number. The PW/PA should be suspended. Also provide 'lsusb -v' for your device (use -d option to select only the affected USB device).
Created attachment 301110 [details] Result of 'aplay'
Created attachment 301111 [details] Result of 'lsusb'
Sure. The results of the two commands are available respectively in the files lsusb.log and aplay.log. I could'nt find a pipewire equivalent of pasuspender and pasuspender itself failed with error 'Failure to suspend: No such entity' so I hope the result of aplay is relevant. PLease tell me what to use to suspend PW if not.
Hello, any thoughts on the logs I sent?
Could you give alsa-info.sh output? Run the script with --no-upload option and attach the output to Bugzilla.
Created attachment 301351 [details] Result of 'alsa-info.sh' Here it is.
So the driver recognizes 5 PCM devices, and aplay/arecord shows it: aplay -l card 2: SL1 [SL-1], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: SL1 [SL-1], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 arecord -l card 2: SL1 [SL-1], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: SL1 [SL-1], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: SL1 [SL-1], device 2: USB Audio [USB Audio #2] Subdevices: 1/1 Subdevice #0: subdevice #0 Is there any missing device?
Created attachment 301353 [details] Inputs shown in Mixxx
Created attachment 301354 [details] Inputs shown in Pavucontrol
Created attachment 301355 [details] Outputs shown in Pavucontrol
Nothing is missing in this report. The card indeed features 2 stereo RCA inputs, 2 stereo RCA output + 1 6.3mm jack input. But Pavucontrol shows only 1 of the 3 inputs and Mixxx (a DJ software) doesn't even show any (see the enclosed pictures). There must be something going wrong somewhere, right?
The complex hardware should be described via UCM - https://github.com/alsa-project/alsa-ucm-conf. PA supports only one device by default. Example config with multiple PCM devices: https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/USB-Audio/Dell/WD15-Dock-HiFi.conf Closing as not a kernel bug.
Reopening. It seems that there is an issue with the capture PCM devices with this hardware. More information: https://github.com/alsa-project/alsa-ucm-conf/pull/187 openat(AT_FDCWD, "/dev/snd/controlC2", O_RDWR|O_CLOEXEC) = 3 ioctl(3, SNDRV_CTL_IOCTL_PVERSION, 0x7ffed85023ec) = 0 ioctl(3, SNDRV_CTL_IOCTL_PCM_PREFER_SUBDEVICE, 0x7ffed850244c) = 0 openat(AT_FDCWD, "/dev/snd/pcmC2D0c", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type) ARECORD **** List of CAPTURE Hardware Devices **** card 2: SL1 [SL-1], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: SL1 [SL-1], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: SL1 [SL-1], device 2: USB Audio [USB Audio #2] Subdevices: 1/1 Subdevice #0: subdevice #0
I don't know if it helps, but here is what I have: (The Rane SL1 was mapped to hw:0 when I typed this command) ``` # ll /dev/snd/pcmC0* crw-rw----+ 1 root audio 116, 3 29 juil. 16:43 /dev/snd/pcmC0D0p crw-rw----+ 1 root audio 116, 12 29 juil. 16:43 /dev/snd/pcmC0D1p crw-rw----+ 1 root audio 116, 13 29 juil. 16:53 /dev/snd/pcmC0D2c ``` So not a privilege problem. The devices simply don't exist.
Yes, then we have to find the reason. The USB audio card structure seems to be probed multiple times for this hardware, so a little piece may be wrong or missing in the driver.
Hi! This issue has been stale for a month. Is there something I can help with?
There is inconsistency in the information. The error indicated /dev/snd/pcmC2D0c, so it's the third card. While you showed the entries of the card 0. If you restart PA or pipewire while keeping the device connected, does it recognize all? Or it's same, some devices still missing?
> There is inconsistency in the information. The error indicated /dev/snd/pcmC2D0c, so it's the third card. While you showed the entries of the card 0. Yes, the logs from the Github issues and comment 14 indicate 3rd card while my last comment indicate first. I'm not sure why the order changed between these two tests made on different days but I can assure you they were made on the same card. > If you restart PA or pipewire while keeping the device connected, does it recognize all? Or it's same, some devices still missing? No, restarting pipewire doesn't change anything. arecord and aplay show the correct number of I/O, but neither alsamixer, KDE sound widget, Mixxx nor Pavucontrol show the 2 missing stereo RCA inputs and they do not appear under /dev/snd/pcmCxDyc. for instance, here's what I have today: !!Soundcards recognised by ALSA !!----------------------------- 0 [Device ]: USB-Audio - USB PnP Audio Device USB PnP Audio Device at usb-0000:08:00.3-2.4, full speed 1 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xf4000000 irq 110 2 [Generic ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xf2500000 irq 112 3 [SL1 ]: USB-Audio - SL-1 Rane SL-1 at usb-0000:01:00.0-1, full speed # Rane SL-1 is 4th device $ ll /dev/snd/pcmC3* crw-rw----+ 1 root audio 116, 18 30 août 16:01 /dev/snd/pcmC3D0p crw-rw----+ 1 root audio 116, 19 30 août 16:01 /dev/snd/pcmC3D1p crw-rw----+ 1 root audio 116, 20 30 août 16:01 /dev/snd/pcmC3D2c APLAY card 3: SL1 [SL-1], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: SL1 [SL-1], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 ARECORD card 3: SL1 [SL-1], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: SL1 [SL-1], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: SL1 [SL-1], device 2: USB Audio [USB Audio #2] Subdevices: 1/1 Subdevice #0: subdevice #0
And it's the result with a UCM profile, right?
(In reply to Takashi Iwai from comment #20) > And it's the result with a UCM profile, right? The problem is not UCM related - the audio device nodes are missing thus they are not accessible from any user space applications. It looks like that udev received some extra events to remove them ?
Ah, I see. Then already tried the delayed registration? If not, check the following: You likely get the kernel information about the delayed registration, something like: Found post-registration device assignment: 13e50001:2 If yes, try to copy the last suggested value and pass it to delayed_register option of snd-usb-audio module as is; e.g. in the case of above, options snd-usb-audio delayed_register=13e50001:2 set in /etc/modprobe.d/rane.conf.
Just FYI (from github - https://github.com/alsa-project/alsa-ucm-conf/pull/187): [ 8827.649083] usb 1-1: new full-speed USB device number 6 using xhci_hcd [ 8827.967295] usb 1-1: New USB device found, idVendor=13e5, idProduct=0001, bcdDevice= 1.00 [ 8827.967301] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 8827.967304] usb 1-1: Product: Serato Scratch LIVE(c)2004 [ 8827.967306] usb 1-1: Manufacturer: Serato [ 8828.026191] usb 1-1: Found post-registration device assignment: 13e50001:02 [ 8828.071190] usb 1-1: Found post-registration device assignment: 13e50001:05
So I filled `/etc/modprobe.d/rane.conf` with the following: ``` options snd-usb-audio delayed_register=13e50001:02 options snd-usb-audio delayed_register=13e50001:05 ``` Now the two stereo RCA inputs are showing but not the mono 6.3mm jack anymore: ``` # ll /dev/snd/pcmC3* crw-rw----+ 1 root audio 116, 18 30 août 19:45 /dev/snd/pcmC3D0c crw-rw----+ 1 root audio 116, 17 30 août 19:45 /dev/snd/pcmC3D0p crw-rw----+ 1 root audio 116, 20 30 août 19:45 /dev/snd/pcmC3D1c crw-rw----+ 1 root audio 116, 19 30 août 19:45 /dev/snd/pcmC3D1p arecord --device=hw:3,0 -f S16_LE -r44100 -s1 -c2 Capture WAVE 'stdin' : Signed 16 bit Little Endian, Fréquence 44100 Hz, Stéréo RIFF(WAVEfmt D��data����� arecord --device=hw:3,1 -f S16_LE -r44100 -s1 -c2 Capture WAVE 'stdin' : Signed 16 bit Little Endian, Fréquence 44100 Hz, Stéréo RIFF(WAVEfmt D��data����� arecord --device=hw:3,2 -f S16_LE -r44100 -s1 -c1 arecord: main:867: audio open error: No such file or directory ``` Also I had to reboot after creating `/etc/modprobe.d/rane.conf`. Is there a way to reload the module `snd-usb-audio` without having to reboot?
You must pass only one delayed_register option, only the second one.
Leaving only `options snd-usb-audio delayed_register=13e50001:05` in `/etc/modprobe.d/rane.conf` doesn't work either. The mono 6.3mm jack input is still missing after a reboot. I also tried leaving only `options snd-usb-audio delayed_register=13e50001:02` but we're back to the original problem.
Then try to pass 13e50001:08 instead. That's the last interface number. I wonder, though, why you didn't get more messages than *:5. If the interface 6 and 7 are actually used, it should show those interface numbers in the messages.
(In reply to Takashi Iwai from comment #27) > I wonder, though, why you didn't get more messages than *:5. If the > interface 6 and 7 are actually used, it should show those interface numbers > in the messages. Never mind, I found the culprit for the missing messages. The check was put only for the case where a PCM stream is added to the already existing PCM instance, and not for the case where a new PCM instance is created. I'll fix this later.
So what's the next move on this? Is there a patch I can test?
Did you try the 13e50001:08 ? Or 13e50001:07. This should work around the missing device problem.
What I meant in the comment 28 was only about the reason why only *:5 appeared in your log. My patch mentioned there won't be about fixing your device, per se, but only for the missing messages. For fixing the actual problem (missing devices), we have to verify the test with the option at first. Once after it's confirmed to work, I can cook the patch.
That's it. :07 did the trick: $ ll /dev/snd/pcmC2D* crw-rw----+ 1 root audio 116, 15 4 sept. 20:22 /dev/snd/pcmC2D0c crw-rw----+ 1 root audio 116, 14 4 sept. 20:19 /dev/snd/pcmC2D0p crw-rw----+ 1 root audio 116, 17 4 sept. 20:22 /dev/snd/pcmC2D1c crw-rw----+ 1 root audio 116, 16 4 sept. 20:19 /dev/snd/pcmC2D1p crw-rw----+ 1 root audio 116, 18 4 sept. 20:22 /dev/snd/pcmC2D2c $ arecord --device=hw:2,0 -f S16_LE -r44100 -s1 -c2 Capture WAVE 'stdin' : Signed 16 bit Little Endian, Fréquence 44100 Hz, Stéréo RIFF(WAVEfmt D��data����� $ arecord --device=hw:2,1 -f S16_LE -r44100 -s1 -c2 Capture WAVE 'stdin' : Signed 16 bit Little Endian, Fréquence 44100 Hz, Stéréo RIFF(WAVEfmt D��data����� arecord --device=hw:2,2 -f S16_LE -r44100 -s1 -c1 Capture WAVE 'stdin' : Signed 16 bit Little Endian, Fréquence 44100 Hz, Mono RIFF&WAVEfmt D��Xdata ����� I wonder, though, why :07 was the correct value since the card only has 5 I/O. This may be not the place, but I want to understand why this worked. Could you explain?
The interface 8 is for MIDI. The cause was that USB-audio driver probes multiple interfaces assigned to the card, one by one. Since it doesn't know how many interfaces will show up easily, it registers the card object at the very first probe. This includes the instantiation of device files. Later interfaces are probed, then those are appended onto the existing card object, re-registering them. OTOH, udev or whatever other processes consider that the control device file (/dev/snd/control*) is the last one that is created for the sound card. So the devices that are created at later points might be missing. I submitted a fix patch for addressing this more consistently now: https://lore.kernel.org/r/20220904161247.16461-1-tiwai@suse.de It's for 6.0-rc4.
You mean it's planned for Linux kernel 6.0? Is it safe to test on 5.19.6? Do you want me to test the patch?
The fix patch is planned for 6.1, as it's a kind of intensive change. What I meant was that the code is based on 6.0-rc4. You can keep the module option until the fix patch gets merged to the upstream and stable tree; the option does basically have the same effect as what the patch achieves.
And for 5.19.x, you need to cherry-pick a few more patches from my current for-linus branch. Otherwise you'll get the patch conflict.
Ok. Thank you all for your time and help!
Hi everyone I was trying to get the Rane SL-1 sound card working with Ubuntu 22.04.01 LTS using the delayed registration, but without any success. I tried specifying everything from *:2 to *:8 but in the end I was always just having access to 1 input and 1 output of the interface. Is there anything which changed already or is there any info I can provide to find a solution?