Re: [PATCH v3] Run PipeWire and WirePlumber in the VMs

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 6286 bytes --]

Alyssa Ross <hi@alyssa.is> writes:

> Demi Marie Obenour <demiobenour@gmail.com> writes:
>
>> 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.
>
> No real objection to udev in VMs.  On the host I'm less sure, because
> ideally the host shouldn't really be interacting with hardware very
> much, so it comes down to whether there are things in scope for the host
> where the kernel doesn't do the right thing by default.
>
>> 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.
>
> systemd is very modular.  I'm not sure you need much of the rest of
> systemd to use the TPM stuff, for example.  The value I'd see in systemd
> would be all the sandboxing stuff for services.  It's annoying because
> none of that has to be part of a single unified service manager either —
> it could largely easily be done by modular chainloaders — but given
> nobody is implementing it outside of systemd there might not be a
> reasonable other choice.  So I'm not really opposed to this either, and
> I guess it probably means we need udev on the host anyway.  I don't know
> when I'd be able to prioritise making the switch, though…

Although at that point we're introducing lots of sockets and global
buses and things that we've so far been very keen to avoid on the host.
I'm really not sure all that additional surface is actually a good
tradeoff compared to doing what defense in depth sandboxing measures we
can easily do ourselves.  The set of software that has to run on the
code is very tightly constrained, so it's a very different situation to
what we'd find in VMs, where we need to be compatible with arbitrary
stuff…

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]