Hacker News Reader

Comment by rektide | Hacker News Reader

Another one of the Linux projects that the cranky contakerous pissy segment of the FOSS world just loves to spit on & hate, PulseAudio.

The FUD keeps coming from within the FOSS world itself. But I keep seeing stuff like this, & thinking, this is such a flexible powerful tokit, pulseaudio- why are so few haters willing or capable of acknowledging that pulse does have serious upsides & vast intermixable capabilities? Maybe it's just me but I feel le Pulse Audio is another one of those epic works that is ceaselessly pointlessly shat upon while no one has anything remotely comparable.

Also though still eager as heck to replace it all & this use case (a frigging awesome ubicomp style use case) with PipeWire. Zeeeerrrooop ccoopppyyyy (to the tune of leroy jenkins).

View on HN

PulseAudio sucked when it first came out, then gradually grew enough features and stability to make it worthwhile. The people still hating on it are just too boneheaded to appreciate things like your speakers muting themselves when you plug in headphones.

That said, it's still glitchy at times and can't do low latency properly, and JACK1 is inefficient, and JACK2 has a messy threading model, and none of them can do any-to-any latency compensation, so let's hope it all gets replaced by PipeWire and we solve this mess once and for all.

I think you are right. I started using linux about 6 years ago and I have never really had an issue with pulse audio. I have had loads of headaches trying to get JACK working which really shows me how smooth PA is to use.

I am still wondering if we'll loose all the network capabilities of PA in PipeWire, whereas I don't need its low latency capabilities. Right now, it looks like one will have to install both PA and PW with a bridge between them, which seems a rather bug-prone setup if you ask me.

I've had huge problems with PulseAudio over the last 14 years, but now there are only two left: it randomly hard-hangs a few times a day and it sometimes stops sending audio to a bluetooth speaker (or occasionally to headphones) while acting as if everything is fine. The latter shows up with speakers from two different manufacturers. Everything else I used to hate about Pulse has gotten better: weird audio distortion, clicking & crackling, skipping, messing up the soundcard enough to require reloading modules, getting stuck on mute, jumping to max volume when things were connected - thankfully all gone.

I've had the hang & audio interruption on Mint, openSUSE, an Ubuntu so I'm inclined to think it's something inside Pulse and I've got some hope that those last bits will get fixed. (I am aware that actually playing sound is the first responsibility of a sound system, but I'm being optimistic here.)

Nobody is going to be able to fix that hang unless they know the steps to reproduce. Can you record pulseaudio with rr and capture it happening? Then debugging it should be pretty easy.

Does JACK even have enough information to do any-to-any latency compensation? The only "Linux audio" application that I know of that really does this now is Ardour, and it was only in the last few years that it was implemented.

That's the problem, the JACK design does not allow for it. It's why Ardour is still gimped and can't actually do full latency compensation if you connect a track to more than one sink, because Ardour is built on JACK, and JACK can't handle that, and the non-JACK backends for Ardour are kept at feature parity. (You can work around this with sends instead of connecting track outputs, since Ardour handles those outside of JACK)

JACK in general provides latency information throughout the chain, but it does not add delay lines to compensate latency itself, so the problem is that when you connect one thing to more than one other thing, the latency number becomes ambiguous (a range) and you can't compensate for it any more.

JACK1 isn't inefficient unless you have parallelizable signal pathways. This isn't the common case, though it is also not unusual either.

I am annoyed by PulseAudio because I don't know how it relates to ALSA.

Every time I made an audio related project on a Raspberry Pi, be it to stream the incoming signal of a USB-mic via ffmpeg/avconv to a server, try to get a ReSpeaker 2-Mics Pi HAT working, stream a MP3 radio stream to a speaker, anything related to sound, I'm always confronted with ALSA as if it were the default audio system on Linux.

But then something doesn't work, and I get referred to PulseAudio, and then I have these two audio systems somehow working together, and I don't know why, but somehow it works, and I'm left clueless about what is going on down there in the OS with all this sound thing.

The .asoundrc file, which is from ALSA, but apparently is used to set up some things in PulseAudio, or not, all this stuff has left me confused as hell.

If PulseAudio is so much better, then why is ALSA the default? Is it even the same, like a replacement?

At least this rant has pushed me now to seek explanatory YouTube videos on this matter, but I think that I'm not the only one who is confronted with this confusion.

Pulseaudio is a middleman between applications and ALSA. There is no Pulseaudio without ALSA.

EDIT: Forgot OSS can also be the back end as an alternative to ALSA

I highly suggest reading the Arch Wiki page on Pulseaudio. https://wiki.archlinux.org/index.php/PulseAudio

> I'm always confronted with ALSA as if it were the default audio system on Linux.

Because it is as far as the kernel drivers for audio devices are concerned. You have to distinguish between that and the userspace part called libalsa.

> If PulseAudio is so much better, then why is ALSA the default? Is it even the same, like a replacement?

Pulseaudio can be seen as a replacement for libalsa while it still talks to the ALSA kernel drivers in usual setups. The fundamental conceptual difference is that pulseaudio is a sound server and libalsa is a library which is directly included into a program.

> The .asoundrc file, which is from ALSA, but apparently is used to set up some things in PulseAudio, or not, all this stuff has left me confused as hell.

This is actually the configuration file for libalsa. The pulseaudio stuff in there is configuration for a compatibility plugin shipped with pulseaudio which presents an audio device to the application using libalsa redirecting everything to pulseaudio instead of directly talking to the Kernel. That way applications without native pulseaudio support can still be used without issues while pulseaudio is running.

I think it's a small but very loud minority that hates on systemd, pulseaudio, etc.

Majority of users, like me, never really comment on those two because they do their job so well - they get out of my way and just work.

Not only do they work, but when you need to advanced stuff it's generally easy & works on the first try. Making loopback devices, combining audio streams and/or redirecting streams, all sorts of wacky stuff. The hardest part is finding a good guide on Google that tells you the right commands/configuration options. Same with systemd.

PA at least was full of bugs on arrival ten+ years ago. That's what started the fight. Poor response to criticism fueled it.

In short, don't replace working code with new until it is at least as good. While new stuff needs testing, folks react strongly when it lands on production systems.

That's definitely true as well - some responses by poettering in systemd issues in particular are unnecessarily condescending and very unprofessional.

Also, while systemd and pulseaudio were heavily pushed by many distros, alsa was and still is an option and systemd alternatives exist for those who care that much.

The biggest problem with all the discussions is that 90% of the people don’t know what they are talking about. A lot of people (and I don’t mean you specifically) treat alsa and PulseAudio as interchangeable but they’re at different levels of the stack. Most PulseAudio installs run on top of Alsa and it’s almost always possible to skip the PA layer and output to Alsa directly so long as the applications were built against libasound as well (and you configure PA not to automatically open your Alsa device).

Compared to systemd I feel like most of the issues with pulseaudio circa 2009 were distro or application specific, like the current situation with Wayland. You could run Ubuntu and have PA eat all your RAM and not even work, but switch to Fedora and not have so many problems (performance was still unacceptable on the toaster I used back then, though). Whereas if you dislike how systemd works and Poettering’s often narrow minded approach, using a different systemd based distro probably won’t change your mind.

> using a different systemd based distro probably won’t change your mind

There's plenty of non-systemd based distros. Yes, they're way less popular, but that's because systemd works and does wonders if you know how to use it, compared to that mess of bash scripts inconsistent in quality and across distro implementations that we had before, so users and developers find value in it.

systemd has certainly made my job as a user, sysadmin and developer a whole lot more pleasant.

If you prefer OpenRC or s6, there's distros for you out there. I won't bother supporting them, but you're free to use them.

Granted, you get outcomes such as [1], but if you're fine with that, the choice is there.

1 - https://gitlab.com/postmarketOS/pmaports/-/issues/719

Sorry if I wasn’t clear - I was saying that people who are unsatisfied with systemd vs earlier or current alternatives are usually better off using a distro based on openrc or runit or s6, as you suggest. Not that there is any lack of good alternatives. The point was that the most common complaints about systemd are indeed issues people have with systemd and not with poor packaging or something. This contrasts with pulseaudio where most of the early criticism was caused more by distros doing a poor job with it than the users having fundamental issues with the design of pulseaudio.

What does that pinephone issue have to do with systemd? Sounds more like a bootloader issue (or if not, the kernel lacking a feature) to me.

> The point was that the most common complaints about systemd are indeed issues people have with systemd and not with poor packaging or something. This contrasts with pulseaudio where most of the early criticism was caused more by distros doing a poor job with it than the users having fundamental issues with the design of pulseaudio.

Fair. I think many would contest that and say they indeed had issues with PulseAudio itself, not because you're wrong, but because the understanding as to why PA sucked for many is just not there and never was. I feel systemd is in a similar position. It's not poor distro packaging, bur it is rather a fundamental misunderstanding of what systemd even is.

From most of the complaints I've heard, they fundamentally misunderstand what systemd is even trying to do, there are certainly better ways of doing them, but I feel the debate is not even at the level where there's understanding of systemd and critiquing it.

In a sense, OpenRC is not even a direct competitor.

> What does that pinephone issue have to do with systemd? Sounds more like a bootloader issue (or if not, the kernel lacking a feature) to me.

It's not bootloader related or kernel related. There are other distros for the PinePhone, like Mobian, where suspend works properly. The issue is Alpine's init system can't do the job. systemd can.

> A at least was full of bugs on arrival ten+ years ago. That's what started the fight.

Right, and the criticisms haven't been updated since.

> While new stuff needs testing, folks react strongly when it lands on production systems

How exactly do you test things if you never roll it out to production. Because "at least as good as the old" is a hard metric, especially given that PA solved a bunch of problems the old code never even attempted.

I think Ubuntu had a particularly bad first PA implementation and that did a lot of the damage. But being on repeat for a decade about how it sucks while it no longer does for the vast majority does not make these people look smart, that's for sure.

I haven't heard any complaints about PA in a long time. Sure, if you dig hard enough you could find some, but nothing like the ground swell of ten+ years ago.

I understand it is very hard to roll out something new and bug-free to production. It's quite easy to not bother, however.

To be fair, the root problem is that the Linux kernel sucks at audio, and everything downstream from that suffers. This sits squarely on the heads of Linus and the maintainers.

For goodness sake, they STILL haven't mainlined PREEMPT_RT support after almost what? ... 20 YEARS. (Although they say they're finally going to ... I'll believe it when I see it.).

You need low-latency for audio to not suck. That requires a kernel re-architecture to enable that.

OS X went through a major kernel revamp back in the 10.3/10.4 timeframe in order to stabilize audio latency.

It's not easy.

> Another one of the Linux projects that the cranky contakerous pissy segment of the FOSS world just loves to spit on & hate, PulseAudio.

There isn't one single anti-PulseAudio comment in the thread, and yet you start a top comment complaining about them, that you fill with insults (and get approved and upvoted for that). I wonder in which camp truly sit the always 'cranky', 'pissy', 'spiting', 'pointlessly shitting' 'haters'.

For all the hate pulse gets, my microphone works more reliably under GNU/Linux than under Windows these days. 2020 is weird, man.

I remain deeply suspicious of second-system-effect "let's replace everything about $THING", but pulse has matured well.

Some problems are hard and there is no good solution but only solutions that suck less than others. Imo pulseaudio and systemd are in this category. So it's easy for haters to find faults in them.

I forgot about Pipewire. How is that project going?

Here is a recent update from Christian Schaller on PipeWire [1]. It looks quite promising; it's especially good to see that PipeWire comes with shims implementing the ALSA, PulseAudio, and Jack API, so it should be a drop-in replacement.

[1] https://blogs.gnome.org/uraeus/2020/09/04/pipewire-late-summ...

There's a significant segment of the community that seems to be afraid of anything that fundamentally rethinks an old subsystem, I believe in large part because it forces them to learn new skills and they're been able to get paid rather handsomely thus far with their teenage-learned Unix skills.

It's a form of gatekeeping.

In my house, PulseAudio powers an entire wireless speaker setup, (except the speakers are actual high-quality bookshelfs, rather than say an Echo and I don't have to wiretap my house).

systemd is another project they love to hate despite what came before being an unreadable, inconsistent mess of variable quality shell scripts that came nowhere close to what systemd provides with its declarative services.

To be fair, while systemd really does provide something that SysV init never could, it is hardly without flaws. In the past, it has had several severe security problems (up to and including privilege escalation vulnerabilities) that the developers have not always handled well. It's a "move fast and break things" kind of software, which in the realm of essential operating system components is not a good quality.

I agree on pulseaudio though, my only real gripe with that is documentation.

> I agree on pulseaudio though, my only real gripe with that is documentation.

Yep not great but still better than that confusing mess called asoundrc.

On top of that PulseAudio appeared to be quite buggy at the beginning for quite some amount time, even after distributions started defaulting to it. I have read that most of those issues were actually driver bugs but that did not stop it getting a bad reputation.

I think this bad reputation is also part of the reason why the hate on systemd escalated that much.

I mean the module-virtual-surround-sink written 8 years ago [1] doesn't even work properly[2]. Even worse the convolution algorithm is a naive implementation with O(n^2) instead of O(nlog(n))[3]. 8 years later it appears the issues are finally being worked on.[4]

[1] https://lists.freedesktop.org/archives/pulseaudio-discuss/20...

[2] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issue...

[3] https://lists.freedesktop.org/archives/pulseaudio-discuss/20...

[4] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

Reply on news.ycombinator.com