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ć
signature.asc
Description: PGP signature
