On 7/19/25 05:22, Alyssa Ross wrote: > 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'll fix this in v5 by only including comments explaining the differences from upstream and removing the conditional overrides. >> 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. I'll add that to the list of debloating tasks. -- Sincerely, Demi Marie Obenour (she/her/hers)