On 7/14/25 10:54, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> 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.
Yeah, I saw this in the log:
N 14:27:54.810067 wp-internal-comp-l ../lib/wp/private/internal-comp-loader.c:588:on_component_loaded: <WpCore:0x28d95d30> optional component 'support.logind [module: libwireplumber-module-logind]' failed to load: failed to start systemd logind monitor: -2 (No such file or directory) N 14:27:54.811299 wp-internal-comp-l ../lib/wp/private/internal-comp-loader.c:640:wp_component_array_load_task_execute_step: <WpCore:0x28d95d30> skipping component 'monitor.bluez.seat-monitoring [virtual]' because some of its dependencies were not loaded E 14:27:54.851210 spa.dbus ../spa/plugins/support/dbus.c:333:impl_connection_get: Failed to connect to system bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory E 14:27:54.852143 spa.bluez5 ../spa/plugins/bluez5/bluez5-dbus.c:6632:impl_init: failed to get dbus connection N 14:27:54.855904 wp-device ../lib/wp/device.c:710:wp_spa_device_new_from_spa_factory: SPA handle 'api.bluez5.enum.dbus' could not be loaded; is it installed? N 14:27:54.856657 s-monitors bluez.lua:411:createMonitor: PipeWire's BlueZ SPA plugin is missing or broken. Bluetooth devices will not be supported. E 14:27:54.859091 spa.bluez5.midi ../spa/plugins/bluez5/midi-enum.c:805:impl_init: Creating GDBus connection failed: Could not connect: No such file or directory N 14:27:54.859810 wp-device ../lib/wp/device.c:710:wp_spa_device_new_from_spa_factory: SPA handle 'api.bluez5.midi.enum' could not be loaded; is it installed? N 14:27:54.860524 s-monitors bluez-midi.lua:95:createMonitor: PipeWire's BlueZ MIDI SPA missing or broken. Bluetooth not supported. E 14:27:54.861346 spa.bluez5.midi.no ../spa/plugins/bluez5/midi-node.c:1989:impl_init: failed to get dbus connection: Could not connect: No such file or directory E 14:27:54.862435 pw.resource ../src/pipewire/resource.c:255:pw_resource_errorf_id: can't create node: Input/output error W 14:27:54.863275 wp-node ../lib/wp/node.c:913:wp_impl_node_new_from_pw_factory: failed to create node from factory 'spa-node-factory' N 14:27:54.863965 s-monitors bluez-midi.lua:130:createServers: Failed to create BLE MIDI server. [0:00:01.314658075] [123] INFO IPAManager ipa_manager.cpp:137 libcamera is not installed. Adding '/nix/store/src/ipa' to the IPA search path [0:00:01.321611889] [123] INFO Camera camera_manager.cpp:326 libcamera v0.5.0
Can we set something in a config file or something to disable this extra stuff?
I started work on a v4 patch, but before sending it I decided to test that not only did PipeWire and WirePlumber start, but also that I could actually play sound to a virtio-sound device I had attached to the VM. This failed rather miserably, and I finally figured out the culprit: PipeWire relies on udev for device discovery, and without udev it doesn't detect any devices. It appears possible to create devices in PipeWire via the PipeWire CLI or via the configuration file. The former would allow them to be created by mdevd, while the latter would be appropriate if the devices were known to be ready before PipeWire started. I strongly recommend using either systemd-udevd (with systemd) or eudev (without systemd) in the host and in any VM that will have real hardware attached to it. udev rules are where all the upstream work on uevent processing is happening, so it fits with Spectrum's "upstream first" mindset. Something simpler like mdevd might be appropriate for VMs that will only ever see virtual hardware with known behavior and do not need to deal with the quirks of real hardware. For the host, I think systemd is probably the right solution. It's complicated, but that is because it solves a complicated problem. Without systemd, Spectrum will wind up needing to reimplement a lot of configuration that has already been written for systemd. Also, systemd has fantastic TPM support. -- Sincerely, Demi Marie Obenour (she/her/hers)