Live data from Hacker News

PulseAudio requirement breaks Firefox on ALSA-only systems

bugzilla.mozilla.org

61–70 of 89 posts

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#61
post #14
post #12

Earlier quoted context omitted.

thanks. this is pretty scary. guess I'll be using Chromium when that day comes, as I'd rather not run PulseAudio.

You could volunteer to rewrite Firefox’s entire ALSA backend to add multiprocess support. That’s what caused this, because Mozilla doesn’t have the manpower to rewrite two backends, and so had to choose one (with the pulse backend being preferred, as the pulse maintainers help mozilla and fix bugs on their side, while mozilla reports getting no assistance or anything from the ALSA maintainers).

I would but they'd have to hire me full time. (Yes, I'd be happy to work on other parts of the browser as well.)

Sad reality is that they are trying to not hire competent people while having features implemented well. Mozilla is vastly understaffed for the magnitude of the project.

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#62
post #22
post #8

Earlier quoted context omitted.

Sadly, pulse is also still quite fragile and has a massive latency. It’d be preferable if for Linux there was an audio server closer to what JACK is (although both JACK and JACK2 aren’t ideal either). (That said, I mix hardware mixing and pulse for my purposes)

> has a massive latency. The trade-off for latency in PA is lower power usage. I think most consume users are pretty happy that their sound system does not suck tons of energy just to offer sub-10ms of audio latency. > JACK AFAIK, PulseAudio and Jack 2 can work pretty seamlessly together thanks to a new dbus API ( https://wiki.archlinux.org/index.php/PulseAudio/Examples#Pul... ).

Mostly, but you will need a tuned kernel setup to have JACK working properly as in no random underruns.

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#63
post #24
post #4

Well, what did anyone expect? Mozilla has complained for quite a while that their ALSA backend hasn’t been supported or updated in years, and they don’t have the manpower to do so. (Especially with their marketshare falling below 8%). So, after calls for people to support it, this is the end result. It’d be delusional to expect them to support two audio backends, and completely rewrite both of them for multiprocess s…

Unfortunately, logic and sanity fall apart when you talk to hardcore Linux users and they get on their tirade about FREEDOM!!!! Check out absolutely any systemd thread for more evidence. Freedom has a high cost - attention, maintenance, and constant vigilance. This is something we are learning all too well in this current political climate in the US. It's something Open Source maintainers are learning as they climb i…

How many PulseAudio but no ALSA installs do you know?

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#64

PulseAudio is a over-complicated piece of bloated shit, like every single project developed by Lennart Poettering. If this man had never entered software development, I would probably not had gone completely insane.

Can you please elaborate further? I think PulseAudio's timer based scheduling is a big improvement over interrupt driven one. Bluetooth audio just works, per application volume control, audio streaming and switching audio sink is painless, you can even configure your resampling algorithm. Even if you use pure ALSA you still have to use a sound mixing server (dmix) since most sound cards these days lack hw mixing. Oka…

It breaks on systems with asynchronous drivers. (E.g. recording timed differently from playback) Those are allowed by ALSA APIs and are present in quite a few high profile embedded Linux devices.

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#65

Honestly, I get it. Alsa is not the future, unless someone steps up and maintains it. And it looks like that's not going to happen. I firmly believe that we should move on. But part of moving on requires that we look at PA's problems. Everytime a PA thread comes up, people disregard and yell at everyone who has a problem with PA. PA has a bad reputation for a reason, and it's not just Pottering hate (though that's li…

Wrong. ALSA is the main Linux audio backend. PulseAudio cannot output to sound devices without it. (only to network) So not supporting it is akin to not supporting audio output on Linux. Dropping PulseAudio is fine if they want to reduce maintenance load, as it is optional, unlike ALSA.

Have you looked at the actual APIs? After last week's announcement, I talked to a friend who has, and apparently the PulseAudio API is much more straight-forward than the ALSA one. He voiced understanding for Firefox supporting PulseAudio instead of ALSA.

EDIT: Also, arguing that Firefox needs to support ALSA instead of PulseAudio because "PulseAudio cannot output to sound devices to ALSA" is similar to saying Firefox should be able to issue SATA commands directly because filesystems would not work without that.

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#66
post #24

Earlier quoted context omitted.

Unfortunately, logic and sanity fall apart when you talk to hardcore Linux users and they get on their tirade about FREEDOM!!!! Check out absolutely any systemd thread for more evidence. Freedom has a high cost - attention, maintenance, and constant vigilance. This is something we are learning all too well in this current political climate in the US. It's something Open Source maintainers are learning as they climb i…

How many PulseAudio but no ALSA installs do you know?

PulseAudio outputs to ALSA, so the numbers should be the same as for KDE installations without Qt.

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#67
post #27

Without going into the whole "to use or not to use PulseAudio" debate, the problem seems to be the fact, that backend which Firefox uses for audio doesn't have anyone who maintains pure ALSA case. So either they need drop pure ALSA support, to find a maintainer or to change the backend. The last two are clearly harder.

> So either they need drop pure ALSA support, to find a maintainer or to change the backend.

The best solution is to use a wrapper library like PortAudio: http://www.portaudio.com/

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#68
post #31

Question for people who are successfully avoiding having to use PulseAudio: is there any particular distro that you are using that you trust not to go down this road? I haven't used Linux as my daily driver for years but I've been looking at switching back recently. It seems a lot harder to avoid PA than it used to be.

It's pretty simple to remove it from SuSE.

That's a relief, I've always liked SuSE.

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#69

Question for people who are successfully avoiding having to use PulseAudio: is there any particular distro that you are using that you trust not to go down this road? I haven't used Linux as my daily driver for years but I've been looking at switching back recently. It seems a lot harder to avoid PA than it used to be.

Arch does not use PulseAudio by default, and I'd be surprised if that changed. It's my daily OS, and I'm quite fond of it.

That's good to know. I take it the rolling release model doesn't bother you? I've never tried it and I'm not sure if the occasional breakage that would happen will drive me crazy.

Re: PulseAudio requirement breaks Firefox on ALSA-only systems

#70
post #38

Question for people who are successfully avoiding having to use PulseAudio: is there any particular distro that you are using that you trust not to go down this road? I haven't used Linux as my daily driver for years but I've been looking at switching back recently. It seems a lot harder to avoid PA than it used to be.

It's not for everyone, but try a BSD. When PulseAudio first started showing up everywhere, I thought it was an anomaly, but it was really a harbinger. Since then Linux has been getting more like Windows every year (unpredictable behaviour, resource-hungry, lots of churn, tons of complexity for little benefit). The FreeBSD audio driver is in the kernel, it's tiny, and I never think about because it's never once caused…

I've been thinking about BSDs. I used to run a FreeBSD server a long time ago and I tend to like copies of the ports system that I've used on other OSes.

How hard is it to upgrade major versions? I seem to remember that this was a pain at some point, but this was so long ago that my memory is fuzzy.

Also, have you had any problems with hardware support? The machine I'm thinking of putting this on doesn't exist yet, so if there is a way I can avoid stupid hardware problems up front it would be useful to know about.

Post reply on HN