Demi Marie Obenour writes: > On 7/18/25 07:27, Alyssa Ross wrote: >> Demi Marie Obenour writes: >> >>> WirePlumber is completely overkill as a session manager here, and >>> ideally a trivial session manager would be used instead. I did build a >>> Spectrum OS image and found that PipeWire and WirePlumber both >>> successfully started. PipeWire is configured to listen on the >>> PulseAudio socket, so PulseAudio compatibility works. This does inject >>> a large number of completely unnecessary files into the VM, notably for >>> libcamera and Bluetooth support. >>> >>> Signed-off-by: Demi Marie Obenour >>> --- >>> >>> Notes: >>> I tested this with QEMU virtio-sound, but I am not sure if the paramters >>> are correct. In particular, the sample rate might well be wrong. >>> >>> img/app/Makefile | 28 +- >>> img/app/default.nix | 18 + >>> img/app/etc/pipewire/pipewire.conf | 291 ++++++++ >>> .../etc/s6-rc/app/dependencies.d/directories | 0 >>> .../app/dependencies.d/directories.license | 2 + >>> .../etc/s6-rc/app/dependencies.d/wireplumber | 0 >>> .../app/dependencies.d/wireplumber.license | 2 + >>> .../etc/s6-rc/dbus/dependencies.d/directories | 0 >>> .../dbus/dependencies.d/directories.license | 2 + >>> img/app/etc/s6-rc/directories/type | 1 + >>> img/app/etc/s6-rc/directories/type.license | 2 + >>> img/app/etc/s6-rc/directories/up | 11 + >>> .../s6-rc/pipewire/dependencies.d/directories | 0 >>> .../dependencies.d/directories.license | 2 + >>> img/app/etc/s6-rc/pipewire/notification-fd | 1 + >>> .../s6-rc/pipewire/notification-fd.license | 2 + >>> img/app/etc/s6-rc/pipewire/run | 20 + >>> img/app/etc/s6-rc/pipewire/type | 1 + >>> img/app/etc/s6-rc/pipewire/type.license | 2 + >>> .../dependencies.d/directories | 0 >>> .../dependencies.d/directories.license | 2 + >>> img/app/etc/s6-rc/wayland-proxy-virtwl/run | 11 - >>> .../etc/s6-rc/wireplumber/dependencies.d/dbus | 0 >>> .../wireplumber/dependencies.d/dbus.license | 2 + >>> .../s6-rc/wireplumber/dependencies.d/pipewire | 0 >>> .../dependencies.d/pipewire.license | 2 + >>> img/app/etc/s6-rc/wireplumber/run | 4 + >>> img/app/etc/s6-rc/wireplumber/type | 1 + >>> img/app/etc/s6-rc/wireplumber/type.license | 2 + >>> img/app/etc/wireplumber/wireplumber.conf | 676 ++++++++++++++++++ >> >> The PipeWire and WirePlumber config files are still very big. Is it >> really not possible to make them smaller and rely on defaults where >> possible? With a whole big config like this, it's difficult to see what >> Spectrum-specific stuff is going on. > > Both of these files are *smaller* than their upstream counterparts. > The main Spectrum-specific stuff is: > > - Nodes are statically set up. This is because PipeWire relies on > udev to enumerate device nodes, and Spectrum VMs don't have udev. > > - A lot of stuff in the upstream configuration files has been > removed. Spectrum's configs should be *smaller* than their > upstream counterparts. > > Neither PipeWire nor WirePlumber has much in the way of a default > configuration. Without a configuration file, neither PipeWire nor > WirePlumber does anything useful. Overriding the defaults and > using the upstream configuration file might be possible, but it > seemed unlikely when I looked. Spectrum VMs are more like > embedded systems than the desktop systems the defaults are made > for. Okay, but there's still stuff that could definitely be trimmed. The comments explaining the syntax of the config file, and the default values, for example. I think they get in the way more than they help because they make the actual non-default settings very sparse. Similarly we probably don't need conditional overrides that are "only applied when running in a VM". > I recommend not including any of the upstream configuration > files and only an allowlist of SPA plugins and PipeWire and > WirePlumber modules. Stuff like Bluetooth can also be excluded. > Just because upstream nixpkgs pulls it in as a dependency does > not mean the configuration in the VM actually needs it. > Ideally, the various plugins and modules would all be separate > build outputs with their own dependencies, and ‘pipewire’ and > ‘wireplumber’ would be meta-packages that pull in all of them. That's an interesting idea. I think it would probably be feasible? And wouldn't share the same maintenance concerns as lots of overrides.