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.