I'm seriously wondering if Spectrum should switch from mdevd to udev. It's where all of the upstream device detection work happens, and it would avoid needing to statically configure sound devices for PipeWire. The current PipeWire patch statically creates devices. This works for VMs because VMs are statically configured and only have virtio devices. This was also the most challenging part of the effort, and I still had to guess some of the parameters. Supporting hotplug would require either a custom PipeWire module, a custom daemon that talked to PipeWire, keeping pw-cli running in interactive mode, or patches to PipeWire to make device lingering work. In the audio case, ALSA expects device paths of the form hw:card:device:subdevice. However, I don't believe card numbers are stable: they reflect the order in which the kernel enumerates devices, and that is not at all guaranteed. A VM that only has a virtio sound device will only ever have card 0, device 0, and subdevice 0, so hard-coding hw:0,0,0 is fine. This is not true if physical hardware is present. That requires a lot of device identification logic, and all of the upstream work on that is in udev or the systemd hardware database (which udev also uses). In the future, there may be other projects Spectrum wants to use that rely on udev for enumerating devices. Some of them might *only* support PipeWire and have no other means of configuration. Even if other means of configuration *exist*, I expect them to be very rarely used by upstream and thus poorly tested. tl;dr: you can get away without udev in VMs, but I expect problems with physical hardware, and I want to switch to udev as a preemptive measure to avoid those problems and to ease development. -- Sincerely, Demi Marie Obenour (she/her/hers)