Comment by scrollaway | Hacker News Reader

Comment by scrollaway | Hacker News Reader

Parent Full thread

There's plenty of things to complain about in Mozilla's and Firefox's development decisions (as I just did in another thread). This is not one of them.

It's far easier to depend on libpulse and have better and more consistent audio support across the board than to have to maintain a bunch of different backends, each with their own set of bugs, some of which are only ever reproducible by one dev on their one machine.

It's also worth noting that at this point, the only users that would complain about this change are either those that have an irrational fear of all things pulseaudio, or those that happen to use distributions that have an irrational fear of all things pulseaudio. It's a better developer experience than alsa and at some point, people will have to move on.

I don't understand, though: On Windows or OSX, when there's massive refactorings and changes in dependencies of builtin software, nobody bats an eye. But on Linux, when something like systemd or pulseaudio comes along, eeeeeverybody's gotta bikeshed about it.

Edit: My comment was unfair. Clarified.

> 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.

Discussing a change in assumptions that alters the core requirements of the most-used user-facing application on the operating system is hardly 'bikeshedding.'

Requiring additional third-party software will never result in 'more consistent' behavior. It merely reduces the userbase to those whose systems look like the developers, and causes your project to be beholden to the whims of the upsream devs.

This is not some architectural decision with a measurable quality impact; it is another abdication on Mozilla's part. We will see more and more of this as their current decline continues. I happen to have no problems with libpulse, but it's pretty clear Mozilla is trying to throw as much as possible over whatever fence they can find. See also Project Mortar.

My own complaints I mentioned are about Project Mortar. Like I said, Mozilla does plenty wrong.

> It merely reduces the userbase to those whose systems look like the developers

Pulseaudio is included by default in almost every Linux distribution. Certainly in every major Linux distribution. This is Mozilla not catering to the 1%. I'm sorry but I cannot see a world in which that decision is incorrect.

I found that of all the people complaining about, for example, systemd, very few actually stepped up to actually maintain the batshit-insane ecosystem of init scripts of their distributions. Those that did, quickly gave up and admitted they were wrong - we had a few of those in Arch Linux when we moved to systemd.

For Pulseaudio, it's the same thing. Who's stepping up to improve the state of Linux audio? In fact, who, of those complaining about pulse, even have a clue about the state of Linux audio and how much of a pain it is to develop for it?

> Pulseaudio is included by default in almost every Linux distribution. Certainly in every major Linux distribution. This is Mozilla not catering to the 1%.

I agree. It's a natural reaction for a company struggling to find its purpose. I hope for all our sakes it helps Mozilla survive.

> Who's stepping up

Well, that's the crux of the problem. Very few people are qualified. Those that are qualified almost universally do not have the backing of Red Hat. It is the opinion of many that both pulseaudio and systemd achieved market dominance because of politicoeconomic reasons, rather than a technological decision-making process. It is very, very hard to prove otherwise... which is why we get these ridiculous religious wars on the topic.

Personally, I don't care. The bugs I've run into in both pulse and systemd are always products of naivete rather than some ficticious malicious plot. Growing pains, like all other projects undergo. The problem we are starting to have is that we are losing portability in the process. The more software requiring libpulse and libsystemd, the more difficult it is for novel approaches to survive.

A posix capability layer is one thing. How does a new player enter the game, when libpulse and libsytemd have no specification? It feels a little like embrace/extend/extinguish.

I have no reason to move away from linux. I have no problem using systemd and pulseaudio on all my systems. But I do understand why some might miss the days when the barier was lower. Dismissing and/or demonizing the people who think that way isn't particularly productive, and neither is telling them their opinions are irrelevant. I hope we move past "if you don't like it reimplement it yourself" one day. The ability to do so was what gave us systemd and pulseaudio, but the requirement that it be done before you can be taken seriously doesn't really add much value.

> The ability to do so was what gave us systemd and pulseaudio, but the requirement that it be done before you can be taken seriously doesn't really add much value.

It's also an insane request because it just can't be done. If I would want to provide an alternative to systemd for the mainstream distros, my first poinft of work would be to implement systemd. Because the environment around me assumes systemd, apart from some safe enclaves.

If I were to provide an incompatible alternative I'd have to win the political war to have it be used or even just considered. Given how upstream looks today that is impossible, even if my solution were excellent. And in that space, nothing can compete against organized paid developers.

And still: People did step up. There still is OpenRC, for example, which is what I'm using. There are the forks that work and provide alternatives. But Linux is more splintered than ever because of that.

The situation with PA and ALSA is better, because ALSA always still worked (I know, because of being an underlying layer, but also without PA, which is nice).

Moving the alsa compatibility code from inline to a third-party library doesn't sound like it alter "the core requirements" by much. Its a 255078 byte package in debian, while firefox itself is ~50MB.

Relying on libpulse is just relying on another layer of the shit sandwich that is the Linux audio stack. Windows and OS X, when they've revamped their audio APIs, the older stuff tends to still work, and tends to be able to take advantage of some of the improvements. Linux audio, on the other hand, is a layer of pulseaudio atop a layer of alsa's userspace components, which is atop a layer of alsa's driverspace components. Instead of people doing things right, and fixing the interfaces that already existed, they added more and more layers of latency-inducing, cpu consuming crap.

While you might be right (I don't know, I have used JACK, alsa, and pulse), for me pulse basically works 99.9% of the time.

Sometimes garbage on top of garbage is the easiest path towards a practical solution. I just want my desktop to make noise and not make me go deaf.

Reply on news.ycombinator.com