alsa-project
ALSA UCM error for Scarlett 18i20 Gen2 with new profile introduced in 1.2.14
I run the Focusrite 18i20 Gen2 on Arch Linux and the recent update of alsa-ucm-conf from 1.2.13-2 to 1.2.14-2 broke the audio output of my device.
May 11 10:33:55 chw90 wireplumber[1636]: spa.alsa: Error in ALSA UCM profile for _ucm0009.hw:USB,0 (HiFi: Direct 2: source): CaptureChannels=20 > avail 18
Reverting to 1.2.13-2 fixes the problem.
Attach output from alsa-info.sh --no-upload. Also, try to determine the capture channel assignment - consult ucm source file https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/USB-Audio/Focusrite/Scarlett-18i20.conf .
I'd like to suggest reverting commit 7283759 that added UCM2 profiles for the Scarlett 18i20. Here's why:
-
The issue reporter and I are both experiencing "Error in ALSA UCM profile" errors with different generations of the 18i20 (Gen2 and Gen4).
-
These interfaces present special challenges for UCM2 profiles:
- Channel counts differ between 1st/2nd Gen, 3rd Gen, and 4th Gen models
- Channel counts differ between firmware versions on 4th Gen
- Channel mappings are fully programmable through ALSA controls, making fixed UCM assumptions problematic
-
The existing Pro Audio profile already handles the most common use cases:
- Simple stereo playback/recording for non-multichannel apps (channels 1/2)
- Full device access for multichannel-aware applications
-
The Direct 2/ADAT profile seems to have limited utility compared to other potential configurations that weren't included.
-
UCM2 profiles seem better suited for hardware with fixed PCM channel mappings, not highly configurable interfaces where users frequently customise routing.
Any UCM2 profile for other cases would probably be specific to the end-user, and maybe more easily done with PipeWire virtual sinks and sources?
UCM2 profiles seem more suitable for hardware that has fixed PCM channel mappings? And you need to be root to update UCM2 profiles, which would be overwritten with the next version of alsa-ucm-conf? I am wondering if it would be better to only have the Pro Audio profile, and develop a tool to make it easier for users to create their own virtual devices for their actual use case?
@geoffreybennett : My opinion is that we should offer something working out-of-box without any extended tools. Then advanced users can switch to something else on demand. If you have information, how to detect the right channel count (USB descriptors?) and the default I/O mapping (without any reconfiguration - right after device boot), please, write it here to fix the current UCM files. Thanks.
I got a differently manifesting, but likely related issue since the update of alsa-ucm-conf 1.2.13-2 -> 1.2.14-1 (or possibly 1.2.14-1 -> 1.2.14-2, sorry not sure ) on Manjaro KDE/Plasma. The connected device is a Focusrite-Novation Scarlett 18i20 1st Gen.
Both pulseaudio (17.0+r43+g3e2bb8a1e) and pipewire-alsa 1.4.2 are crash-looping with a segfault in libasound2. This is triggered once the KDE desktop audio panel is opened, thus might be an issue there, but it's certainly rooted in the alsa-ucm-conf change, resulting in a broken audio setup with this interface.
`journalctl` shows:
[connecting the device]
Jun 11 18:42:40 x280n kernel: usb 3-1.3: new high-speed USB device number 14 using xhci_hcd
Jun 11 18:42:40 x280n kernel: usb 3-1.3: New USB device found, idVendor=1235, idProduct=800c, bcdDevice= 2.7a
Jun 11 18:42:40 x280n kernel: usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 11 18:42:40 x280n kernel: usb 3-1.3: Product: Scarlett 18i20 USB
Jun 11 18:42:40 x280n kernel: usb 3-1.3: Manufacturer: Focusrite
Jun 11 18:42:42 x280n kernel: usb 3-1.3: Quirk or no altset; falling back to MIDI 1.0
Jun 11 18:42:42 x280n mtp-probe[17619]: checking bus 3, device 14: "/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb3/3-1/3-1.3"
Jun 11 18:42:42 x280n mtp-probe[17619]: bus: 3, device: 14 was not an MTP device
Jun 11 18:42:43 x280n boltd[1374]: probing: started [1000]
Jun 11 18:42:43 x280n mtp-probe[17665]: checking bus 3, device 14: "/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb3/3-1/3-1.3"
Jun 11 18:42:43 x280n mtp-probe[17665]: bus: 3, device: 14 was not an MTP device
Jun 11 18:42:46 x280n boltd[1374]: probing: timeout, done: [2947524] (2000000)
[here i opened the plasma audio tray panel, initially showing the device, but then crashing]
Jun 11 18:42:57 x280n kernel: show_signal_msg: 411 callbacks suppressed
Jun 11 18:42:57 x280n kernel: data-loop.0[8306]: segfault at 100000001 ip 0000775312b2dc20 sp 00007753137009d0 error 4 in libasound.so.2.0.0[87c20,775312ac8000+94000] likely on CPU 2 (core 2, socket 0)
Jun 11 18:42:57 x280n kernel: Code: ff ff ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 41 8d 4f ff 45 85 ff 0f 84 37 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <41> 8b 34 24 49 01 d4 89 33 48 01 c3 83 e9 01 73 ef e9 12 ff ff ff
Jun 11 18:42:57 x280n systemd-coredump[17675]: Process 8304 (pipewire) of user 1000 terminated abnormally with signal 11/SEGV, processing...
Jun 11 18:42:57 x280n systemd[1]: Started Process Core Dump (PID 17675/UID 0).
Jun 11 18:42:57 x280n systemd-coredump[17676]: [🡕] Process 8304 (pipewire) of user 1000 dumped core.
Stack trace of thread 8306:
#0 0x0000775312b2dc20 snd_pcm_area_copy (libasound.so.2 + 0x87c20)
#1 0x0000775312b4bb4e n/a (libasound.so.2 + 0xa5b4e)
#2 0x0000775312b1dc10 snd_pcm_avail (libasound.so.2 + 0x77c10)
#3 0x0000775312c0c432 n/a (libspa-alsa.so + 0x2c432)
#4 0x0000775312c0ec1a n/a (libspa-alsa.so + 0x2ec1a)
#5 0x0000775312c0fe2d n/a (libspa-alsa.so + 0x2fe2d)
#6 0x0000775314890d66 n/a (libspa-support.so + 0x6d66)
#7 0x00007753147c05f3 n/a (libpipewire-0.3.so.0 + 0x235f3)
#8 0x00007753146427eb n/a (libc.so.6 + 0x957eb)
#9 0x00007753146c5fb4 __clone (libc.so.6 + 0x118fb4)
Stack trace of thread 8304:
#0 0x00007753141dd9d7 n/a (libpipewire-module-protocol-native.so + 0x209d7)
#1 0x00007753141c4bce n/a (libpipewire-module-protocol-native.so + 0x7bce)
#2 0x00007753141c5064 n/a (libpipewire-module-protocol-native.so + 0x8064)
#3 0x000077531488ee88 n/a (libspa-support.so + 0x4e88)
#4 0x0000775314890d66 n/a (libspa-support.so + 0x6d66)
#5 0x00007753147ddce0 pw_main_loop_run (libpipewire-0.3.so.0 + 0x40ce0)
#6 0x00005797c2196575 n/a (/usr/bin/pipewire + 0x1575)
#7 0x00007753145d46b5 n/a (libc.so.6 + 0x276b5)
#8 0x00007753145d4769 __libc_start_main (libc.so.6 + 0x27769)
#9 0x00005797c2196705 n/a (/usr/bin/pipewire + 0x1705)
Stack trace of thread 8305:
#0 0x000077531464ae22 n/a (libc.so.6 + 0x9de22)
#1 0x000077531463efda n/a (libc.so.6 + 0x91fda)
#2 0x000077531463f024 n/a (libc.so.6 + 0x92024)
#3 0x00007753146c6475 epoll_wait (libc.so.6 + 0x119475)
#4 0x00007753148a1447 n/a (libspa-support.so + 0x17447)
#5 0x0000775314890caf n/a (libspa-support.so + 0x6caf)
#6 0x000077531480e0d7 n/a (libpipewire-0.3.so.0 + 0x710d7)
#7 0x00007753146427eb n/a (libc.so.6 + 0x957eb)
#8 0x00007753146c5fb4 __clone (libc.so.6 + 0x118fb4)
ELF object binary architecture: AMD x86-64
Jun 11 18:42:57 x280n systemd[1]: [email protected]: Deactivated successfully.
Jun 11 18:42:57 x280n systemd[1]: [email protected]: Consumed 202ms CPU time, 80.1M memory peak.
Jun 11 18:42:57 x280n pipewire-media-session[8563]: ms.core: error id:0 seq:12304 res:-32 (Broken pipe): connection error
Jun 11 18:42:57 x280n xdg-desktop-por[1796]: Caught PipeWire error: connection error
Jun 11 18:42:57 x280n plasmashell[1860]: kpipewire_logging: PipeWire remote error: -32 connection error
Jun 11 18:42:57 x280n systemd[1691]: pipewire.service: Main process exited, code=dumped, status=11/SEGV
Jun 11 18:42:57 x280n systemd[1691]: pipewire.service: Failed with result 'core-dump'.
Jun 11 18:42:57 x280n systemd[1691]: pipewire.service: Consumed 22.185s CPU time, 41.7M memory peak.
Jun 11 18:42:57 x280n systemd[1691]: Stopping PipeWire Media Session Manager...
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: context kaput
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: context kaput
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n kded6[1836]: org.kde.pulseaudio: No object for name "alsa_input.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_output.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n plasmashell[1860]: org.kde.pulseaudio: No object for name "alsa_input.pci-0000_00_1f.3.analog-stereo"
Jun 11 18:42:57 x280n systemd[1691]: pipewire.service: Scheduled restart job, restart counter is at 5.
Jun 11 18:42:57 x280n systemd[1691]: Started PipeWire Multimedia Service.
I dont know much about alsa config, but it seems to me that providing a generic default config as before and letting users decide what config to use is the right move, given that these devices are so flexible in their routing (see below), likely mostly being used in professional contexts where users already have their routing setups customized. So i also agree with @geoffreybennett wrt a revert of this config due to a mismatch with users needs.
If you have information how to detect the right channel count (USB descriptors?) [..]
According to @geoffreybennett, this is a multifactorial issue, not just depending on USB descriptors but also firmware versions; seems hard to get right. I assume that this will not be solvable by fail-forward with a fixed config in the near term (lacking a large user base providing feedback on this). So in order to provide a working setup for users of these devices again, i agree also in this regard, that a revert is the sensible move to provide a fix asap
[...] and the default I/O mapping (without any reconfiguration - right after device boot) [...]
Not sure if you're talking about the same kind of configuration, I'm not too deep into alsa config -- but from my understanding this is not how these devices work: they can persist a channel routing when configured via Focusrite's config tool (alternatively via something like https://github.com/geoffreybennett/alsa-scarlett-gui, but i didnt use that so far), so default config will differ between devices. Not sure if this matters in this case, but i wanted to point it out, in case it isn't known.
@geoffreybennett is not right. We can detect the firmware using raw USB descriptors, because the supported channel count is a part of the USB descriptors.
Please, provide raw USB descriptor file for firmware with 18 channels - the contents is in sysfs tree like /sys/bus/usb/devices/2-2.4/descriptors .
The fix may be like: https://github.com/alsa-project/alsa-ucm-conf/pull/524/files
... because the supported channel count is a part of the USB descriptors.
The number of available channels also depends on the active altsetting/sampling rate. For example see alsa-info attachments in [1], specifically the USB Stream information section.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=214493
@puleglot I don't think that's an issue because https://github.com/alsa-project/alsa-lib/issues/388 "For configurations using split macros, the default rate is hardcoded to 48kHz in the alsa-lib direct plugins"?
@puleglot I don't think that's an issue because alsa-project/alsa-lib#388 "For configurations using split macros, the default rate is hardcoded to 48kHz in the alsa-lib direct plugins"?
Split macros is only used in HiFi profiles. But something needs to be done for Direct profiles as well.
As for HiFi, it may also not be so with <<<SplitPCM=1>>> which Pipewire uses nowadays to do splitting without ALSA plugins, and then the device may get opened at different sampling rate than 48kHz depending on configuration.
I've just upgraded to Fedora 42 and am getting this error now for my focusrite 18i20 gen 4.
reverting to 1.2.13 fixes my problem. With 1.2.14, here is the alsa-info.txt file:
It seems this problem has now shipped in Debian 13
EDIT: manually removing the changes of 7283759a381ca1fc2589da213daa05f9d3b84aac on my system has restored function to my audio interface on Debian 13.
The pipewire graph also looks normal again (checked with qpwgraph), which was an incredible mess on version 1.2.14 with the 18i20 split up into dozens of separate devices.
