I'm trying to wrap my head around the pipewire ecosystem. I think it's great that we're getting a fully featured audio system with all the upsides of pulseaudio and jack, and none of the downsides (that I know of), plus a bunch of completely new features. However, I can't help but think it could have used a little more vision in its interface (or maybe just qpwGraph).
From what I've read, my mental model is that pipewire holds the graph, while a "session manager" manipulates it (create/modify/remove new nodes/ports/links/etc). That's fine. I also understand that wireplumber is such a session manager, and despite having a really convoluted config syntax, it does its job (I assume).
As a simpleton, though, I'm drawn to the wysiwyg interface of qpwGraph, but it's not clear to me how it's supposed to fit into pipewire's vision or how it interacts with wireplumber. It seems to render the current pipewire graph as it is, it can create/remove links between ports, but also it's not a session manager (right?).
I suspect that whatever I can do in qpwGraph I could also do using just wireplumber via conf files and the cli. But dragging my mouse between nodes is so much easier than learning a new syntax. But then I also don't understand what "Active" and "Exclusive" mean. I'm guessing that if Active isn't checked, it won't do anything at all, but if Exclusive isn't checked then...maybe wireplumber can override it? Does that mean if Exclusive IS checked it's able to override wireplumber (look at me, I am the session manager now)? Is that why, if I have a qpwgraph active that links VLC to both OBS and my headset, I hear/see a delay of the link to my headset when a VLC process launches? First wireplumber decides where it should link, and then qpwGraph modifies it several ms after?
I feel like it's currently not clear what qpwGraph is in pipewire terms, but it's also clearly the most intuitive way for someone to use pipewire right now. I think it would be best if qpwGraph was either a standalone, fully featured session manager (not to be used in combination with wireplumber) or just a front end for wireplumber rather than talking to pipewire directly.
Thoughts? Anyone else confused? Am I missing a piece to the puzzle?
I disagree that it's the same for multiple reasons: first off the project and telemetry were never profit-driven. Their goal was always to use modern methods of software development to make the software better.
The fact is, these days all for-profit projects gather a ton of info without asking, and then use that data to inform their development and debugging (and sell, but that's irrelevant to my point). To deny open source software the ability to even add the option of reporting telemetry is to ask them to make a better product than for-profit competition, with fewer tools at their disposal, and at a fraction of the pay (often on a voluntary basis). That's just unreasonable.
Which is why the pushback wasn't that they were using telemetry, it was that they were going to use Google Analytics and Yandex, which are "cheap" options, but are obviously for-profit and can't be trusted as middlemen. They heard the concern over that and decided to steer away to a non-profit solution.
But as a software dev and a Linux user, I often wish I could easily create bug reports using open source, appropriately anonymized telemetry reporting tools. I want to make making a better system for me to use as easy as possible for the saints that are volunteering their time.
As for the issues in tenacity, it was likely specific to what I was doing. I was rapidly opening and closing a lot of small audio clips, and saving them to network mounted dirs under different names. I remember I had issues with simple stuff like keyboard shortcuts to open files, and I had to manually use the mouse to select a redundant option every single time (don't recall what it was), and I think it would just crash trying to save to the network mounted dir, so I had to always save locally and copy over manually. So I just switched back and continued my work.