Comment by onli | Hacker News Reader

Comment by onli | Hacker News Reader

Parent Full thread

> On Windows or OSX, when there's massive refactorings and changes in dependencies of builtin software, nobody bats an eye.

In Windows and OSX, the builtin software is not stuff we can influence. When Apple decides to use another soundserver that is what happens. There are no different expectations. Linux is a different beast.

Take me as example. I just got burned often enough by pulseaudio that I really don't want to try it again. When it was introduced there were countless support threads in the linux forum I frequented at the time with broken systems, and also my own did only work when I reverted to ALSA. Also later, when everything was supposed to work, PA just did not work for me. Yes, I'm using it by now on my laptop, but it's not like that is a flawless experience – and I highly assume PA is at least partly responsible for the issues with the sound system on there.

Now, it's not only pulseaudio. See what the Gentoo wiki writes (https://wiki.gentoo.org/wiki/PulseAudio):

> This is the only supported configuration by upstream and Gentoo developers.

> PulseAudio uses udev and ConsoleKit to dynamically give access to the soundcards to the currently "active" nr. When running Systemd this will be handled without needing ConsoleKit.

ConeoleKit is unmaintained and to my understanding bloat that is just completely unnecessary, especially on my single user desktop system. And of course systemd won't come on my main system, I completely oppose it. Relying on PA means moving into the wrong part of Linux.

Maybe it won't be a big problem in the end, with the ALSA code still being available. Still, not a good thing, and in my eyes indeed a development decision one can complain about.

Here's the thing though, none of that is supposed to matter. End users most definitely are not supposed to care what their sound server is. These are decisions that, ideally, are taken by the distributions.

Think about it this way: Okay, you got burned by Pulseaudio. But why was it your job to debug these issues? Why was it your job to decide to go back to Alsa, rather than fix them?

Now when a distribution decides to provide multiple configurations then it's also the distribution's responsibility to ensure everything works correctly. When a distribution like Gentoo decides to shift that responsibility to the user, expect to be burned - but don't expect upstream to be friendly to you.

Same for systemd. No end user should care. System administrators sure will care, but 99% of sysadmins I've talked to love systemd... so that's not the issue.

As a Linux enthusiast I'm sorry that this is the state of things, but this is the price we pay for customizability. This is the price of being able to change every little setting, every little modular bit of software, every library providing imperfect 90% compatibility with every other library.

Pulseaudio/systemd complaints are IMHO a symptom of a far worse overarching issue with Linux. They showcase the failures of direct democracy. The lack of context that users have and give. When a user says "I want to stay on Alsa", what they really mean 99% of the time is "I had a bad Pulseaudio experience that one time, and I heard a ton of bad things, so give me Alsa". Those same users don't understand the difficulties of supporting, in alsa, configurations that they don't necessarily use such as bluetooth headsets; configurations that other users ask for.

Thus, the failure of direct democracy: "I want what works for me, not what works for everybody".

> "I want what works for me, not what works for everybody"

Except we just said it doesn’t work for everybody. PulseAudio breaks audio on my computer. ALSA just works. Until PulseAudio also just works, I don’t want to use it.

This is because you are unable to configure PulseAudio properly despite the very good documentation it has. (It could use better one for the internals though.)

- ALSA to PulseAudio routing works much better than most native ALSA drivers. This used to be not true a bunch years back. (alsa-pulse in alsa-plugins) It is the default in many important distributions.

- You can also force PulseAudio to not take over hardware devices and still use default or other ALSA device. This requires disabling a hardware detect module so you will lose some hotplug potential.

- There are also ways to make it interoperable with Jack. Simple in fact. Works better than all ALSA to Jack approaches in my experience.

- One remote possibility is that you are using a sound card which has a broken ALSA driver. PulseAudio tries to use advanced features such as mmap, rewinding and buffer monitoring to reduce latency and improve performance. If one of those pieces is broken in some subtle way, it could fail. (generally crackle) In this case, this needs debugging work in ALSA side. Other applications also use some of those features.

> Okay, you got burned by Pulseaudio. But why was it your job to debug these issues?

Because it's his computer? Who else's job might it be? He only has a few options: fix it himself, pay someone else to fix it, convince someone else to fix it for free, or do without sound.

It's the same with less knowledgeable users, except they don't have the option to fix it themselves.

Exactly what I was thinking. I've never owned a Linux computer where I was promised any kind of support. If something goes wrong, I get to fix it or do without, so I end up caring about the inner workings much more than I would with a Windows computer.

Pulseaudio never worked properly on any of my setups, across several machines, several distributions and many years. Problems vary: no sound at all, sound stopping after a while, sound interrupted by silences, insane CPU consumption for little or nothing and I probably forgot a few.

ALSA does. It used to have configuration problems but that's not the case any more.

After more than 20 years of Linux, I have very low expectations concerning the state of sound in Linux, but PulseAudio does not even fulfil them. PulseAudio is now banned from any of my computers.

Ok, but here's a counterpoint: for five years now I've been running Mageia Linux on a variety of laptop, desktop, whatever, all with Pulse and I've never had a problem. Like, none. I wouldn't even know how to diagnose it if I did, but since it never happens, I never think about it.

So...consider me a satisfied Pulse user, I guess, except I don't even think about it. For me, Linux audio is just a solved problem.

For me, the pro audio part could use more work. Dealing with underruns in Jack is annoying and mostly kernel fault. (Because ffado FireWire works great.)

Last time I had a linux desktop for both work and fun, what worked was oss4. Not pa, not alsa.

Then oss4 is banned from the kernel, and asking about it got me even banned on spot without explanation on some irc channels and forums.

Then people try to convince me linux is ready for desktop adoption and people stay on windows because inertia...

That last time must have been more than 10 years ago and/or you were using a sound card which had no drivers made yet. (or finished)

OSS4 has a different set of drivers. It sucks at both latency and maintenance though in all of them.

> Think about it this way: Okay, you got burned by Pulseaudio. But why was it your job to debug these issues? Why was it your job to decide to go back to Alsa, rather than fix them?

Two reasons:

1. I was at the time supporter at ubuntuusers.de, the german Ubuntu forum

2. When Ubuntu moved to pulseaudio it botched the upgrade. Rather, PA just sucked and did not work on many systems, there was not much Ubuntu could've done better apart from sticking to ALSA or moving to another soundserver.

Now, currently on my system it's because I decided actively to not use specific parts of the "modern" Linux system. No sytemd, no pulseaudio. I'm working on this machine and I want software that works.

> Those same users don't understand the difficulties of supporting, in alsa, configurations that they don't necessarily use such as bluetooth headsets

This is exactly the area where my laptop system with PA makes issues. The bluetooth headset just does not work reliably. It works sometimes and sometimes not.

Yes, it's the price of customizability, you're right about that. But the solution of moving to complicated and broken bigger frameworks, and additional layers of abstraction, just is no solution. Make the stuff that does not work work – didn't the BSDs stay with OSS and now have a really good soundsystem? Or convince people of better solutions by making better solutions that actually work, instead of shoving broken software (PA) or broken software with innacceptable design decisions (systemd, binary log) via distro upgrade without provided alternative down people's throat. The mainstream distros are making it wrong.

Iirc, the OSS thing was a license issue rather than a technical issue. the BSDs, being under that MIT license, do not have to deal with how to ensure future freedoms.

>Why was it your job to decide to go back to Alsa, rather than fix them?

That might be easier said than done. My 10+ year old Pulseaudio showstopper bug has produced at least one patch, but as of yet that patch has not been accepted.

So an important point... It isn't just that Pulseaudio is buggy, we have no real way of resolving the issue without a fork.

Reply on news.ycombinator.com