Arsen, I've read parts of your new and previous message. Replying to them is beyond what my time affords, and I'm not willing to take part in a conversation in this style.
-Roman On Mon, Mar 2, 2026 at 7:29 AM Arsen Arsenović <[email protected]> wrote: > > Roman Žilka <[email protected]> writes: > > >> This is a distinct topic and was covered already with the PipeWire + > >> PulseAudio default change a little while ago, though. > > > > I think that was a bad change [...] > > You've not provided a single reason for me to agree with you so far. > Let me assure you, I do not. Repeating that this is a bad change does > not make it true. > > The *default configuration* has been made to support sound *on desktop* > *by default* in the way both us and our upstreams, whether DE > developers, sound system maintainers, or sound-producing programs, > recommend or assume. The instigating incidents (the three bugs you > mentioned) are only part of the reason why this is a good change. > > The alsa-lib based stack you're advocating for (presumably, since you > keep pointing out that PA and PW are "unnecessary") is *not* functional. > > (Side note: PA/PW is very disingenuous; they're not interchangeable) > > The alsa-lib based stack: > > - Is bitrotted (tried getting a tiny patch upstream?), > - Isn't supported by many programs, > - Cannot adjust per-program volumes, > - Doesn't do anything to support video-related functionality, > - Isn't even meaningfully smaller or less resource heavy (have you > measured the load of running dmix in each audio-engaging process?), > and > - Isn't the default anywhere else. > > And, to pre-empt "bandwagon" arguments. A lot of people doing something > does not make it bad. It does not make it good either. It makes it > more tested. What makes this good is that it is more tested, and that > PipeWire is a good design that resolves many previous deficiencies. > > So, it isn't a bad change. Simple as. Repeating that it is doesn't > make it true. > > Mind you, I am well aware that you *can* avoid them, and I did up to > pipewire becoming mainstream (because PA really wasn't great), but to > argue that avoiding them ought to be the default when that configuration > is bit-rotted and in many ways unimplemented is an untenable position. > > You know that such a configuration requires significant setup to be > functionally "equivalent" (but not really). Why you keep ignoring that > simple fact is beyond me. > > > [...] and the three bugs that it was based on lead me to think that > > you didn't give much thought to how dispensable PA/PW is. > > Based on what? Provide these thoughts that should've inhibited the > change, please? And reason to believe nobody thought about it? > > The change was made by people who thought about it, obviously. > > The change isn't the removal of these USE-flags. > > > In the wild of the internet, people deal with PA/PW time and again as > > if they equaled audio in Linux. > > They might as well be. Programs assume them. But, even if they aren't, > it does not matter. USE flags still exists. > > > In Fedora and Ubuntu they kind of do, but that's just because they > > lack USE flags and have to make packages with everything compiled in > > for the sake of every last use case. > > > > But if there's a global flag or flags for all things PA and PW > > (possibly minus rarely installed things like some games), I'll be > > satisfied. > > There is. If there weren't, you'd have PipeWire installed already. > > You already know that there is. Per this, you should be satisfied. > > >> > volume control, per-app volume control, output to any physical output, > >> > ...) and, of course, video use cases (very few people screencast > >> > outside of videoconferencing, which doesn't need PW). > >> > >> This is covered in the news item that Paul referred to, but no, it's > >> used on Wayland DEs to show previews of windows as well, for example. > > > > That's a poor reason for a whole new service in the system. > > It isn't. Repeating this does not make it correct. > > > Well, it seems that what's actually required is to review every > > package with the USE "pipewire" to see if that shouldn't be renamed to > > "screencast" or "pulseaudio". "pulseaudio" meaning the universal API, > > so it can really be PA or PW. Then, it'll be possible to decide what > > to do with what's left with "pipewire": make a global "pipewire" (with > > the meaning "PipeWire native API", if I understand it right), do > > nothing, or something else yet (like individual renaming of "pipewire" > > to something more specific). > > Frankly, I don't see how this is not currently the status quo. PipeWire > is in relative terms new, how'd there have been a confusion between > PipeWire and PulseAudio USE-flags given that the latter have been added > long before the former? > > Please file bugs with your examples. > -- > Arsen Arsenović
