Not sure if this is the right forum, feel free to migrate.

**** List of PLAYBACK Hardware Devices ****
card 0: Gen [Scarlett Solo 4th Gen], device 0: USB Audio [USB Audio]
  Subdevices: 1/1

switching outputs/inputs is very buggy - the radio buttons stay on when clicked and dont switch off when another button from the same category is selected. plugging the interface out and in again causes them to reappear, all unselected. sometimes none appeared (im unsure why), with the interface marked as an 'inactive card' in the settings. manually switching it from 'Off' makes the output and inputs reappear in the GUI
attempting to play audio from a source produces the following message in journalctl:

pipewire-pulse[4505]: mod.protocol-pulse: [] timeout on stream 0x564424417420 channel:6
pipewire-pulse[4505]: mod.protocol-pulse: [] timeout on stream 0x564424f446e0 channel:7
pipewire-pulse[4505]: mod.protocol-pulse: [] timeout on stream 0x564424deea10 channel:8
pipewire-pulse[4505]: mod.protocol-pulse: [] timeout on stream 0x564425022780 channel:9
pipewire-pulse[4505]: mod.protocol-pulse: [] timeout on stream 0x5644248bc8b0 channel:10

all of the audio outputs and inputs appeared correctly in pavucontrol. while attempting to play audio from a youtube video, the output always defaulted to some "Unknown output". trying to switch to a different one, like the interface's headphone output, produced no audio. the selected output would get replaced by "Unknown output" after a few seconds
the node priorities from pw-cli ls Node appear to be correct as far as i understand:

 		node.name = "Dummy-Driver"
	id 30, type PipeWire:Interface:Node/3
--
 		node.name = "Freewheel-Driver"
	id 57, type PipeWire:Interface:Node/3
--
 		priority.session = "100"
 		priority.driver = "1"
 		node.name = "Midi-Bridge"
 		media.class = "Midi/Bridge"
--
 		priority.session = "2100"
 		priority.driver = "2100"
--
 		node.name = "alsa_input.hw_Gen_0"
 		node.nick = "Monitor Input 3"
--
 		priority.session = "1100"
 		priority.driver = "1100"
--
 		node.name = "alsa_output.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Line1__sink"
 		node.nick = "Scarlett Solo 4th Gen"
--
 		priority.session = "2100"
 		node.description = "Scarlett Solo 4th Gen Input 1 Inst/Line"
 		node.name = "alsa_input.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Mic1__source"
 		node.nick = "Scarlett Solo 4th Gen"
--
 		node.name = "alsa_input.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Line3__source.split"
 		media.class = "Stream/Input/Audio/Internal"
--
 		priority.session = "2100"
 		node.description = "Scarlett Solo 4th Gen Monitor Input 3"
 		node.name = "alsa_input.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Line3__source"
 		node.nick = "Monitor Input 3"
--
 		node.name = "alsa_input.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Mic2__source.split"
 		media.class = "Stream/Input/Audio/Internal"
--
 		priority.session = "2100"
 		node.description = "Scarlett Solo 4th Gen Input 2 Mic"
 		node.name = "alsa_input.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Mic2__source"
 		node.nick = "Scarlett Solo 4th Gen"
--
 		node.name = "alsa_input.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Mic1__source.split"
 		media.class = "Stream/Input/Audio/Internal"
--
 		node.name = "bluez_midi.server"
 		media.class = "Midi/Bridge"

below is also a comparison of output from pactl list short sinks. the first is on the most recent wireplumber version, the 2nd is when everything is functioning properly after a downgrade:

126	alsa_output.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Line1__sink	PipeWire	s32le 2ch 48000Hz	   SUSPENDED

249	alsa_output.usb-Focusrite_Scarlett_Solo_4th_Gen_S1QQKEM360B9CC-00.HiFi__Line1__sink	PipeWire	s32le 2ch 48000Hz	IDLE
257	alsa_output.usb-Generic_USB_Audio-00.HiFi__SPDIF__sink	PipeWire	s16le 2ch 48000Hz	SUSPENDED
258	alsa_output.usb-Generic_USB_Audio-00.HiFi__Speaker__sink	PipeWire	s32le 2ch 48000Hz	SUSPENDED
259	alsa_output.usb-Generic_USB_Audio-00.HiFi__Headphones__sink	PipeWire	s32le 2ch 48000Hz	SUSPENDED
262	alsa_output.pci-0000_12_00.1.hdmi-stereo-extra2	PipeWire	s32le 2ch 48000Hz	SUSPENDED

restarting wireplumber only causes the inputs & outputs to briefly disappear from the GUI, that's the only discrenible effect i can spot. restarting the whole audio stack similarly has no useful effect.
so far ive only managed to avoid this problem by staying on the 0.5.15-1 version of wireplumber. if im on 0.5.17-1 and my audio is broken, downgrading to 0.5.15-1 and restarting wireplumber during the same session instantly makes the audio work properly again. i couldnt find any other posts concerning an issue like this, and im unsure how to diagnose it on my system further. the bug being tied solely to the version of wireplumber i have installed leads me to believe theres something wrong with it specifically, especially with how seamlessly it starts working again after i downgrade and restart it. of course, staying on an old version is a bad idea in the long term, so ill be very grateful for advice on how to address this odd behavior :)

... I did get an invite to the matrix server so we're all good there. ...

Hi community,

I'd appreciate for an invite to the matrix server too.
('email me' should work to contact me)

How to get VCC in standby without such an ugly hardware hack?

If the motherboard doesn't implement this, you can't. Who knows whether it does, on which ports, and why vendor stripped down some BIOS options.
A hardware without proper documentation is just a bulk of metal and sand.

Sure, unpowered device can't signal remote wakeup. Assuming USB HUB remains powered, according to /proc/acpi/wakeup.

If a device violates USB specification, it can't pass USB certification and can't label itself "USB compatible".
Many semi-DIY devices violate the spec. Usually nothing bad happens: if such device is plugged into USB port powered from mains 5V, power just cuts off in standby. If the port is powered from 5VSB, auxiliary PSU is powerful enough not to burn out. Some implementations may detect overcurrent and either wake up or cut power off, it depends™.

Many systems use s2idle instead of deep sleep. It allows to manage power more granulary but requires support from software side, which is hard to implement for proprietary products. Related question is why chipset driver doesn't turn CPU fan off in s2idle on your system.

for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done

You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

But it's amdgpu, HDMI and hyprland runs at rgb888 - so probably same situation.
The details might still help AMD to locate the bug.

yes, with pacman -Si

How would that work - the dependency would only be shown in the dependent package which is what is sought and currently unknown.  An expac invocation could get the job done, but not `pacman -Si ...`.

EDIT: I suppose `pacman -Si` without any arguments technically would include the required information, but it'd be buried among nearly 300K lines of output that would need to be parsed with a non-trivial awk or sed script to find candidates that *might* be the relevant package.  So theoretically possible, but really a very very bad way to arrive at the sought after answer.

EDIT 2: running `pacman -Sii <new-dependency>` (two i's) in contrast could be useful.

but these don't seem to work. I also wrote the udev rule mentioned, but since deleted it out of concern that it may have been causing an issue. pipewire.socket pipewire.service pipewire-pulse.socket pipewire-pulse.service wireplumber.service are all enabled and running. No amount of restarting units or rebooting seems to have an impact on this, either in making it work or not.

You can ask KDE developers to convert them to JPEG-XL when making the distribution tarball. Plasma already supports the format. A 10x compression almost for free.

I am happy enough just not installing that package at all, which is now easily possible with the package no longer being a required dependency of plasma-meta.

If someone else cares about making the package smaller, I suppose they'll have to ask upstream themself. Although anyone can also simply download the package, extract the wallpapers they want, convert them to JPEG-XL or do whatever. Personally I don't really see the point in having them as a package anyway, but as long as it is easy to avoid having it installed I'm not complaining.