Scarlett Solo USB profiles missing or broken in 1.2.11

[Slabity]

Prior to version 1.2.10, my Scarlett Solo USB profiles looked like the following, where I could select profiles that explicitly enabled or disabled either the Inputs or Outputs:

As of 1.2.11, these profiles have disappeared and have left only a couple of profiles that do not provide the same functionality:

Other devices like my GPU's HDMI/DP Audio and motherboard's "Starship/Matisse HD Audio Controller" continue to expose the wider variety of profiles. It is only this device that seems to have the issue.

I originally reported this on #346 as I thought it was related, but was told it might be a different issue. What makes me worried is the mention that this is "expected" now despite it breaking my audio setup. I can no longer select the "Digital Stereo (IEC958) Input" to exclusively enable the Input Device without enabling the Output Device.

Here's some more information about the device:

$ lsusb | grep Focusrite
Bus 007 Device 003: ID 1235:801c Focusrite-Novation Scarlett Solo USB

$ alsaucm listcards
  0: hw:2
    Focusrite Scarlett Solo USB at usb-0000:10:00.3-3, high speed

$ alsaucm -c hw:2 dump text
Verb.HiFi {
    Comment Default
    Device.Line1 {
        Comment "Headphones / Line 1-2"
        Values {
            CaptureCTL "_ucm0001.hw:USB"
            PlaybackCTL "_ucm0001.hw:USB"
            PlaybackPCM "_ucm0001.hw:USB"
            PlaybackPriority 200
        }
    }
    Device.Mic1 {
        Comment "Input 1 Mic"
        Values {
            CaptureCTL "_ucm0001.hw:USB"
            CaptureChannels 1
            CapturePCM "_ucm0001.scarlett2i_mono_in:USB,0,0"
            CapturePriority 200
            PlaybackCTL "_ucm0001.hw:USB"
        }
    }
    Device.Mic2 {
        Comment "Input 2 Inst/Line"
        Values {
            CaptureCTL "_ucm0001.hw:USB"
            CaptureChannels 1
            CapturePCM "_ucm0001.scarlett2i_mono_in:USB,0,1"
            CapturePriority 100
            PlaybackCTL "_ucm0001.hw:USB"
        }
    }
}
Verb.Direct {
    Comment "Direct Scarlett Solo USB"
    Device.Direct {
        Comment "Direct Scarlett Solo USB"
        Values {
            CaptureCTL "_ucm0001.hw:USB"
            CaptureChannels 2
            CapturePCM "_ucm0001.hw:USB"
            CapturePriority 1000
            PlaybackCTL "_ucm0001.hw:USB"
            PlaybackChannels 2
            PlaybackPCM "_ucm0001.hw:USB"
            PlaybackPriority 1000
        }
    }
}

Some OS info it it helps:

Linux distribution: NixOS on nixpkgs-unstable Kernel: 6.7.7 ALSA version: Advanced Linux Sound Architecture Driver Version k6.7.7 Pulseaudio version: 15.0.0 Pipewire version: 1.0.3

[Slabity]

I also just want to add that this wouldn't be an issue if I could split default Input/Output devices within pavucontrol but that doesn't seem to be possible for some reason. All applications try to take this device as the default Output device if I try to enable it as the default Input device, and I can't seem to change this behavior within the program.

[perexg]

It's a question for the sound server rather than UCM profiles. With pavucontrol, you can route specific applications to specific sinks/sources (first two tabs) and the sound server will remember that, but you would like to tell the system to use input from one sound card and the output from another. Using a wrong profile (as you did it using generic profiles to keep running only one direction) does not solve this issue completely.

It does not seem like UCM issue, but a more general (sound server) configuration issue. I would suggest to open a discussion in the sound server related forums.

[kepstin]

In particular, the problem that you mentioned in https://github.com/alsa-project/alsa-ucm-conf/issues/346#issuecomment-1975315568 - "when that output exists then various applications try to use it as the primary output device for some reason" - indicates that you have a problem with your pulseaudio (or pipewire) configuration.

Having multiple available output devices is a perfectly normal state, and it's up to the sound server to let you pick which one to prefer, and to direct applications to use that output by default.

[Slabity]

This can be closed I guess. I solved the issue by buying a monitor that doesn't have broken headphone jack.