Sound on linux is never getting easier, isn't it?

[Anon-E-moose]

[rab0171610]

Pipewire has been relatively trouble free for me as well. I use JamesDSP for equalization personally. I just picked a Graphic Eq setting from the builtin AutoEQ database that sounded as close to my settings on PulseAudio EQ and modified it. I then saved it and created a rule to load it at startup.
There were a lot of headaches with PulseAudio over the years. I had to modify the config files for every machine with PulseAudio. What worked on one machine did not work on a another, it was always system specific and often trial by error as the documentation was difficult for me to understand.

Anyway, my point earlier was that Pipewire is now widely adopted and considered the default among most distros and users. However, it is one thing to say it is an improvement and it is another to say it is a "big leap forward" without specifics as it just sounds like hyperbole to the average Linux user, especially when that statement is alone the basis for recommending to uninstall PulseAudio and install Pipwire instead. "It is a big leap forward."

It seems like every time a project gets abandoned and an new one takes its place to fulfill the same functions (with improvements) I hear the same things but without specifics. Trust me, this is a big leap forward, this is the future, forget about such and such and install this. The old project code was old and bloated so we started from scratch. Forget about that, pretend it never happened, it is horrible, this is great. Pay no attention to the Poettering behind the curtain. It would be nice for people to step out from behind the curtain, give specifics, and be transparent about why the newer replacement projects are better and improved over the previous solutions. I hear the same things about SystemD, for example. SystemD is better than SysVinit. SysVinit is dead, don't use that, its horrible. SystemD is wonderful and new, it is a big leap forward. All the while when asked for specifics, all I ever heard, generally speaking, was SystemD could improve your boot times because it supports parallelization of services.

I don't have an issue with progress, new projects, and change -- I now use SystemD and Pipewire and Wayland. But, I do wish that people promoting these newer, improved replacement projects would provide specifics about the improvements instead of just telling people to switch or else.

[Anon-E-moose]

I run wayland, not even xwayland, as I've gotten rid of all X related stuff.
X is not getting new development, wayland is.
In the same way pulse development is going to be abandoned in favor of pipewires, since pipewire is a superset of alsa, pulse and jack.

A big improvement? From an end user perspective, maybe, maybe not. From a developer view, a pretty good improvement.

I've never used pulse, never installed it on my system, as I had no personal use for it, and I stay away from major DE's like gnome or kde
and thus wasn't forced to accept it. But pipewire was easy to install and start using and if I ever want to use pulse or jack in pipewire
it's just a matter of flipping bits.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[mrbassie]

[Anon-E-moose]

mrbassie, Do the same thing with wireplumber.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[lars_the_bear]

[pietinger]

[pjp]

[lars_the_bear]

[szatox]

[pjp]

@lars_the_bear,

I used Ubuntu once via USB flash drive so I can't comment on Canonical's support. RH (pre-IBM) wanted your money, but did not want to provide support. Has Google ever provided support for a product they've kept? I've never heard a good thing about support from either MS or IBM. As for the use of Windows, my experience is that there is no business justification ($) to change. And I doubt there are any "meaningful" reasons for a manager mist(er|ress) to want that flag in their cap which would likely end up looking less like a flag and more like having been fired.
_________________
Quis separabit? Quo animo?

[lars_the_bear]

@pjp

Broadly, I agree. But I fear I have already dragged the discussion further off topic than anybody would thank me for.

BR, Lars.

[Spanik]

[dmpogo]

[Ralphred]

"Do one job, and do it well"
We are all familiar with this phrase, and what happens when as a paradigm, it is ignored.

This is the history of "Audio on linux" - ignoring the paradigm. Just think about it for a second and look at the 3 most popular offerings in the "linux audio stack"

First, there is ALSA: As a driver you have to make some pretty "poor choices" as a Linux user to not have ALSA support at a hardware level, but it sucks as a mixer/router, and the API, at least the way it's implemented by some application devs, is "less than optimal".
Then there is Pulseaudio: At a hardware level has atrocious support as it tried to use a "config wizzerd", and makes the assumption that it's "documents"(lol) will help with corner cases sidestepped by said "wizzerds". It's pretty good at mixing, almost "totally shit" at routing, but has a great API for programmers - as in, if pulse or you get your hardware and routing to work, everything else "just werks" after that.
Finally we have Jack: Requires you to sort out your own ALSA*, so hardware support is "on you". Master of routing and mixing (even in a non-RT environment), but not as ubiquitous as Pulse as far as application support goes.


My overall opinion on this whole thing is there needs to be 3 parts to your "sound stack" :

• Client API (simple for application devs to use).
• Routing and mixing "server" (Simple for end users to use/manipulate).
• Hardware "connection" (simple** for distro-devs, power-users, and sys-admins to set-up (once!)

"But Ralph,", you say: "you've ignored pipewire!". Indeed I have, because it ignores the paradigm, and until such time I'm forced to replace one of the above components with it, I will continue to do so...

In conclusion, sound on Linux is simple: Constrain pulseaudio so it doesn't try and fsck with your ALSA hardware config - your apps will all "work", and so will your sound hardware. If you need "advanced routing" slap Jack in between pulse and ALSA. If you are losing CPU cycles to "redundant processing of no-audible sound" RTM again 'cus you did it wrong.
IMHO, this is very much the "Gentoo way", read: You put in all the "real effort" at inception, then the rest is smooth sailing.

*There are Jack management apps that attempt to "auto-configure" ALSA for you, but rather like Pulseaudio they fail on corner cases (small mercy that Jack's documentation has yet to be been found wanting as much as PA's is though).
**"simple" in the case can just mean "well, and accurately, documented".

[lars_the_bear]

[lars_the_bear]

[pjp]

[dmpogo]

[Spanik]

[CaptainBlood]

[Zucca]

I'm just getting more familiar with this guide.
Looks like the author has put real effort into it.
_________________
..: Zucca :..