Re: [PATCH v9 2/2] img/app: Run PipeWire and WirePlumber in the VMs

[Alyssa Ross <hi@alyssa.is>]

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

Demi Marie Obenour <demiobenour@gmail.com> writes:

> On 7/29/25 09:08, Alyssa Ross wrote:
>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>> 
>>>  create mode 100644 img/app/etc/pipewire/pipewire.conf
>>>  create mode 100644 img/app/etc/s6-rc/app/dependencies.d/wireplumber
>>>  create mode 100644 img/app/etc/s6-rc/pipewire/dependencies.d/dbus
>>>  create mode 100644 img/app/etc/s6-rc/pipewire/notification-fd
>>>  create mode 100644 img/app/etc/s6-rc/pipewire/notification-fd.license
>>>  create mode 100644 img/app/etc/s6-rc/pipewire/run
>>>  create mode 100644 img/app/etc/s6-rc/pipewire/type
>>>  create mode 100644 img/app/etc/s6-rc/pipewire/type.license
>>>  create mode 100644 img/app/etc/s6-rc/wireplumber/dependencies.d/dbus
>>>  create mode 100644 img/app/etc/s6-rc/wireplumber/dependencies.d/pipewire
>>>  create mode 100644 img/app/etc/s6-rc/wireplumber/run
>>>  create mode 100644 img/app/etc/s6-rc/wireplumber/type
>>>  create mode 100644 img/app/etc/s6-rc/wireplumber/type.license
>>>  create mode 100644 img/app/etc/wireplumber/wireplumber.conf.d/99_spectrum.conf
>> 
>> We have app depending on wireplumber, but no notification-fd for
>> wireplumber.  What's actually required here?  Does Wireplumber actually
>> need to be running (for whatever definition thereof) by the time an
>> application starts, or does it just need to start at some reasonable
>> point?
>
> The latter.  In systemd terms, this is WantedBy=.  I will fix this by
> having ok-all depend on WirePlumber, while the app no longer does.

Yep, that's the right fix.

>>> +    # PipeWire chooses the node with the highest priority.driver value as
>>> +    # graph driver, which is the node that decides when the processing graph
>>> +    # is going to run.  If both the capture node and playback node are in
>>> +    # the same graph, the capture node should be chosen as the driver.  This
>>> +    # is because the driver gets to choose the rate of the graph and so is
>>> +    # much less likely to xrun.  Since capture xruns result in corrupted
>>> +    # audio recordings, while playback xruns just result in a glitch, it
>>> +    # is more important to avoid capture xruns.
>>> +    #
>>> +    # When there are multiple sources or sinks that could be used,
>>> +    # WirePlumber links application nodes to the one with the highest
>>> +    # priority.session value.  In the configuration created here,
>>> +    # there are two valid audio sources: the virtio sound card's
>>> +    # capture stream and the monitor of its playback stream.  The
>>> +    # capture stream is the correct choice, so its priority.session
>>> +    # should be higher.
>>> +    #
>>> +    # The recommendation to give the capture device higher values
>>> +    # for priority.driver and priority.session comes from George
>>> +    # Kiagiadakis of Collabora, who also provided the values
>>> +    # used (2000 and 1000) and why they must be different.
>>> +    # The explanation for why it is more important to avoid
>>> +    # capture xruns than playback xruns comes from past discussions
>>> +    # that I (Demi Marie Obenour) had with Wim Taymans.
>> 
>> Just checking: they're okay with being credited, right?  (Important for
>> me to be confident before mentioning anybody in an immutable log.)
>
> That's actually not something I had checked.  I asked both if they are
> okay with this.  Should I sent V10 without these, or should I wait
> for a response from them?

Send a new version without it, and then we can add it in later if you
get a response.  If the discussion was public, an alternative would be
to just link to the discussion.

>>> diff --git a/img/app/etc/wireplumber/wireplumber.conf.d/99_spectrum.conf b/img/app/etc/wireplumber/wireplumber.conf.d/99_spectrum.conf
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..277e6019c46582afba12af9b1a27bb16ddd9e804
>>> --- /dev/null
>>> +++ b/img/app/etc/wireplumber/wireplumber.conf.d/99_spectrum.conf
>>> @@ -0,0 +1,42 @@
>>> +# SPDX-License-Identifier: MIT
>>> +# SPDX-FileCopyrightText: 2019-2021 Collabora Ltd.
>>> +# SPDX-FileCopyrightText: 2025 Demi Marie Obenour
>>> +
>>> +# Copyright © 2019-2021 Collabora Ltd.
>> 
>> Once again I'm surprised any of this is © Collabora…
>
> It's out of an abundance of caution.  All of this is taken from
> the wireplumber.conf files in Arch and Nixpkgs, which I believe
> are just the upstream ones.  I suspect you are correct, but
> it's much better to keep a copyright notice that is not needed
> than to remove one that actually *is* needed.

Well, keeping it can also cause problems in the event of relicensing,
etc.  In a marginal case, I'd keep the notice too, but I just think
there's no way there's anything copyrightable remaining in this case.

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