Add conditional channel count on Scarlett 18i20 version#660
Add conditional channel count on Scarlett 18i20 version#660dathegreat wants to merge 1 commit intoalsa-project:masterfrom
Conversation
|
My understanding from #559 is that the channel count also depends on the flashed firmware version. The raw USB descriptors can be matched using new syscard/type=hex substitutions (alsa-lib 1.2.15+) like used in 0515e5b . If you can collect contents of |
Based on what geoffreybennett said, it seems like the firmware is only relevant for the 4th gen model. I unfortunately only have a 2nd gen, so I can't provide the descriptor files myself. @geoffreybennett do you have a 4th gen handy to get the descriptors from? (Side note, I use alsa-scarlett-gui every day. Thank you so much for all your work making Scarlett interfaces plug-and-play on Linux). It looks like @zzzeek also mentioned having a 4th gen. Could you supply the descriptors too, zzzeek? |
|
Hi - Sure, let me know if this is what you need, this file is |
|
FWIW, here are the descriptors from the 2464 firmware for 18i20 4th Gen. I still think that trying to build a specific 18i20 config is a lost cause and 7283759 should be reverted. @perexg I see your argument about having something working out of the box, and I agree. That's what the Pro Audio configuration already did for people. Now it's broken depending on the channel count of your device and there is this incomprehensible selection between HiFi and HiFi: I think that anyone with an 18i20 is going to have their own specific use case, and the only sort of configuration that comes close to being standard/generic/usable out of the box for most people will be having Stereo Out on channels 1-2 and Mono or Stereo In on channels 1-2. Creating separate virtual devices for every pair of outputs becomes overwhelming: Especially on the 4th Gen now, the default routing has changed, with PCM 1&2 going to line outputs 1&2 and headphones 1&2. So the Pro Audio configuration even gives you headphone output out of the box for free. There's also no way to avoid extended tools with the big 4th Gen units - the firmware shipped with them is unusable enough that the units ship with an "Update Required" sticker over the USB port. |
|
the 1.2.13 behavior for me is completely perfect whereas the 1.2.14/15 behavior is unusable for me. I use it with qjackctl to route the actual PCM in/out to things, I have full access to the device and that all works great with 1.2.13 (and with 1.2.14/15 explodes where I dont really know what's going on) so from my (very outside end-user) perspective I don't see what needs to be changed exactly from what 1.2.13 does. |
|
@geoffreybennett : There's conflicting device "Line 6" with "Line 1" defined in current UCM configuration. It's the reason why you see two HiFi profiles: alsa-ucm-conf/ucm2/USB-Audio/Focusrite/Scarlett-18i20-HiFi.conf Lines 254 to 256 in 5d175e1 PipeWire shows the "internal" UCM device names ( @zzzeek : What you mean with unusable? You cannot select "Direct" or "Pro" profiles ? I assume that you may hit the channel detection bug. In this case, pipewire might fail to probe the card. Thank you all for the descriptors. I will give a look (I was hoping someone would show the difference between USB descriptors and analyze it to focus only on the UCM part). Note that I'm not author of those configurations files. If there should be any correction, I'm open to it. |
|
Difference between descriptors provided from @zzzeek and @geoffreybennett : Diff bcdDevice 18.65 -> 19.00Used tool: https://eleccelerator.com/usbdescreqparser/ @Zzeek : Could you also provide output from |
ALSA stream0 dump for Scarlett 18i20 4th Gen bcdDevice 18.65 |
|
Table with channel counts (p = playback, c = capture):
|
|
@dathegreat : Could you also show your |
|
@perexg here are all the values I could find. This seems super-difficult though; surely there's a better way? If you think we really need a HiFi conf for all models, could we just have a simple one like this? descriptors-2301.gz |
Link: alsa-project#660 Signed-off-by: dathegreat <d.a.thegreat123@gmail.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Use bcdDevice number (using sysfs) to detect the right channel count. Information is taken from the pull request comments bellow. Link: alsa-project#660 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
|
I updated table in #660 (comment) and created PR #675 with bcdDevice number matching to set the correct channel count. Any feedback is appreciated.
The question is why pipewire does not offer better identifiers in qpwgraph / pulseaudio sink/source mappings. UCM does the right job with the channel split IMHO. |
|
Also, if someone has a clue about routing (meaning) of the additional 6 channels, please, keep a note. Also, channel mapping for 96kHz and 192kHz is missing. I would like to try create UCM configs (profiles) for those combinations, too. |
Link: alsa-project#660 Signed-off-by: dathegreat <d.a.thegreat123@gmail.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Use bcdDevice number (using sysfs) to detect the right channel count. Information is taken from the pull request comments bellow. Link: alsa-project#660 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
|
A proposal to have multiple direct profiles: PR #680 , see https://github.com/alsa-project/alsa-ucm-conf/pull/680/files#diff-4474c3b8f08283f87a7121c2f6dfec806f26eb405bd73ebc9d3256830753c8b5L97 . |
The extra 2 playback and 6 capture channels are for supporting dual-ADAT I/O (16 channels). Why 2p/6c extra when dual-ADAT should require an 8 extra channels? It could be an artificial limitation, or maybe the hardware couldn't support more than 26 PCM channels each way, but 26 channels is enough to run 16 ADAT and 10 analogue playback channels and 16 ADAT, 8 analogue, and 2 loopback recording channels independently. You just need to reassign some of the channels away from (e.g.) headphones to ADAT. There is no inherent meaning to the channels, only the purpose the user assigns them to in the device, either in Linux with alsa-scarlett-gui, or in Windows/Mac with Focusrite Control 2. The device remembers its configuration, and so it's a bad assumption to think that any PCM channel is going to correspond with any particular input or output. FWIW, this is the 2464 firmware default routing for 48kHz: 
The firmware has independent channel maps for 96kHz and 192kHz, but I've never looked up (until just now) what those defaults are because the Linux driver always sets the the 96kHz and 192kHz routing tables equal to the 48kHz routing table upon any edit (obviously just leaving out the sinks that don't exist at the higher sample rates). The Focusrite Control 2 application does the same. Also FWIW, here are the channel maps (format: sink <- source from the hardware's POV) directly after an erase-config. Most interestingly, the firmware defaults for the different sample rates are actually different! So once you make any change, it is not possible to get back to exactly the same firmware default settings using alsa-scarlett-gui or Focusrite Control 2. Because these devices are so flexible, it would be much better to have a tool for users to easily set up their own profile to exactly match the configuration that they are using rather than have a generic profile that matches nobody's configuration but the person who created it. |
I'm sorry, I don't understand what this is meant to do? I tried to test it anyway: pavucontrol shows: 
Maybe that's a step forward? It's not showing the "[ALSA UCM error]" that I was previously getting: |
Use bcdDevice number (using sysfs) to detect the right channel count. Information is taken from the pull request comments bellow. Link: alsa-project#660 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Please, retry, if you like. There was a typo in the configuration, so pipewire probably used legacy profiles. There should not be any error for the ucm dump text command. Thank you for your test and for the channel map. It's also necessary to uncomment 96kHz and 192kHz section to make those direct profiles available -
Right. But it would be better to have something to start with and expose all channels. And if we have UCM configuration tool in future to reduce or refine configurations for this complex hardware type, all sound cards can share one code instead maintain a specific tool for one hardware. |
I don't think that's the real problem? You mentioned ConflictingDevice so I tried removing that, and then I only see one HiFi configuration (and none of that "Direct1, Direct2, ..." stuff in the description). I have a vague idea of what ConflictingDevice is meant to do, but cannot figure out its relevance to the 18i20. I have to admit I barely understand UCM, and my only experiences with it so far have been uniformly negative, even before 1.2.14 broke many users' 18i20 setups. I can see UCM making sense for fixed-function cards, for the smallest Scarletts, and for the Vocaster One and Two. But for larger interfaces with general-purpose I/O, UCM just gets in the way. A while back I created configurations for every Scarlett exposing every stereo output pair, and every input as mono and stereo which theoretically would be great for non-multichannel-aware applications, but the real-world usability was terrible. My conclusion: for these larger interfaces, everyone's better off using Pro Audio, and creating virtual PipeWire/PulseAudio devices for any specific needs. The UCM2 format is, frankly, inscrutable: 548 lines of highly redundant, difficult-to-follow configuration with a less usable end-result. And, forgive me if I'm wrong, but I don't think there's even a way for users to sensibly override it with a better configuration? Since it's in 
|
Okay, I retried and
I don't understand what direct profiles are, or how to test them. I'm going on vacation soon, and won't be able to do much for the next few weeks.
I'm not clear on what you mean by "expose all channels"? The Pro Audio configuration already does this. Or you mean expose as individual virtual devices? That's a lot of virtual devices! For playback, it's reasonable to do stereo-only pairs of outputs, so that's 13 playback devices. Then for recording you want to support both mono and stereo recordings. That's 26+13 = 39 devices. As I said in my other message, I already created such UCM configurations, and the usability in applications is just atrocious because none of them expect to have 39 recording devices available. And still, the default firmware routing does not expose all physical channels individually. The current 18i20 profile is already too tall to fit on my monitor, and it doesn't cover the very common use case of someone wanting to do a stereo recording, let alone a stereo recording from any pair of channels. But it does have an 8-channel virtual ADAT input (connected to the wrong inputs depending on model!) for some unknown reason. 
I don't understand what this would mean practically? By "specific tool for one hardware" you are referring to alsa-scarlett-gui? A UCM configuration tool would be a good idea, but I don't see how that would remove the need for it. |
UCM direct profile is identical to Pro profile created by pipewire. All channels, no remapping. The goal is to have 3 direct profiles for all channel count variants (different rates). |
You can override the configuration by creating |
|
While I appreciate all the work done for this issue, I don't see any progression made on issue #588 . It was closed as an duplicate of issue issue #559 , that in it's self has a pull request into this draft. But all I see is talk about the channel count of gen 2 to gen 4. No talk about the issue I have with my gen 1 interface. While I can use a workaround mention in #588 that let's me use my interface in my DAW and many other programs, there is still a UMC error flag in shown in my KDE system settings with the device. Also I experience some problems with certain games based on Unreal Engine, that will crash on startup due to - as I assume - this error flag. I would love to see a fix to this problem, especially as the changes in the device config mentioned in the workaround seems to resolve all the the functioning problems with the device and only the error flag is tainting my experience. |
|
@Kuroiban : Could you show your bcdDevice and channels numbers from |
|
@perexg: Sure. This is with the workaround applied, manually setting the capture channels to 18 from 20 in /usr/share/alsa/ucm2/USB-Audio/Focusrite/Scarlett-18i20.conf and Scarlett-18i20-HiFi.conf Focusrite Scarlett 18i20 USB at usb-0000:0d:00.3-3, high speed : USB Audio Playback: Capture: |
perexg
force-pushed
the
master
branch
10 times, most recently
from
90b4ed1 to
67998e1
Compare
Link: alsa-project#660 Signed-off-by: dathegreat <d.a.thegreat123@gmail.com> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Use bcdDevice number (using sysfs) to detect the right channel count. Information is taken from the pull request comments bellow. Link: alsa-project#660 Signed-off-by: Jaroslav Kysela <perex@perex.cz>
6 participants
Resolves #559