Demi Marie Obenour writes: > On 7/29/25 09:08, Alyssa Ross wrote: >> Demi Marie Obenour 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.