PulseAudio requirement breaks Firefox on ALSA-only systems(bugzilla.mozilla.org)
bugzilla.mozilla.org
PulseAudio requirement breaks Firefox on ALSA-only systems
https://bugzilla.mozilla.org/show_bug.cgi?id=1345661
88 comments
In this case it's just behind a use flag, but regardless it seems to me like this could be fixed with a relatively simple wrapping library.
SDL for example supports outputting to OSS, ALSA, PulseAudio, ESD and with a patch, JACK. What you want to output to can be easily configured at runtime. You as a developer write the least code possible and only have to do the job once, your users get the benefit of picking any output system they please.
I believe Gstreamer offers a similar system too which Mozilla already uses for video decoding on Linux.
Additionally the same code can be used across other platforms entirely, not just Linux.
SDL for example supports outputting to OSS, ALSA, PulseAudio, ESD and with a patch, JACK. What you want to output to can be easily configured at runtime. You as a developer write the least code possible and only have to do the job once, your users get the benefit of picking any output system they please.
I believe Gstreamer offers a similar system too which Mozilla already uses for video decoding on Linux.
Additionally the same code can be used across other platforms entirely, not just Linux.
Firefox is cross platform. It has to support Win32/64 sound, Linux (alsa/pulse), whatever the hell FreeBSD and MacOS use ..
Back in 2013 I had a lot of issues with Steam games not running correctly with PulseAudio (lots of static instead of sound half the time I tried to start a game). Sometimes doing a killall on the pulseaudio server would help, sometimes it would not. On that machine, I added a -pulseaudio USE flag in Gentoo and removed it entirely.
On my current machines, I do use Bluetooth audio and find PA easier to deal with. I also no longer play games on my Linux boxes.
I'm also old enough to remember the horrors of ESound and the KDE one (whatever it was called) and how audio would constantly be out of sync.
Pulse is a lot better and seems to do well today. Still Pulse has some huge limitations. Run two X servers and use either consolekit or systemd? Good luck trying to get audio to continue playing on both X servers at the same time. It won't. Want to run MPD as a system daemon? You'll need to figure out how to enable TCP in Pulseaudio.
I don't run SystemD, but I do run Pulseaudio. Those are my choices. Gentoo still gives me that choice, which is why I use it as my home and work distro. Void is another great Linux distribution that gives you such choice as well.
Like I started with, Firefox has to support a ton of audio backends for various operating systems. We're not talking about maintaining OSS support. Pulse still depends on ALSA in the Linux kernel for it to work, so ALSA isn't going away any time soon. There's no reason for Firefox to need to depend on that intermediary layer and remove direct access when that already exists.
Back in 2013 I had a lot of issues with Steam games not running correctly with PulseAudio (lots of static instead of sound half the time I tried to start a game). Sometimes doing a killall on the pulseaudio server would help, sometimes it would not. On that machine, I added a -pulseaudio USE flag in Gentoo and removed it entirely.
On my current machines, I do use Bluetooth audio and find PA easier to deal with. I also no longer play games on my Linux boxes.
I'm also old enough to remember the horrors of ESound and the KDE one (whatever it was called) and how audio would constantly be out of sync.
Pulse is a lot better and seems to do well today. Still Pulse has some huge limitations. Run two X servers and use either consolekit or systemd? Good luck trying to get audio to continue playing on both X servers at the same time. It won't. Want to run MPD as a system daemon? You'll need to figure out how to enable TCP in Pulseaudio.
I don't run SystemD, but I do run Pulseaudio. Those are my choices. Gentoo still gives me that choice, which is why I use it as my home and work distro. Void is another great Linux distribution that gives you such choice as well.
Like I started with, Firefox has to support a ton of audio backends for various operating systems. We're not talking about maintaining OSS support. Pulse still depends on ALSA in the Linux kernel for it to work, so ALSA isn't going away any time soon. There's no reason for Firefox to need to depend on that intermediary layer and remove direct access when that already exists.
I do run MPD as a system daemon, can't recall having to do anything crazy with Pulseaudio...
Maybe your distro has it configured by default. I had to modify config (you can change the one in your home directory or the system on in /etc/pulseaudio/default) to include something like
module-native-protocol-tcp auth-ip-acl=127.0.0.1
Note that by default in most distributions, pulse starts running when a user logs in, and runs as that user, but it can easily be configured to run as a system daemon instead to support multiple user sessions using it at the same time.
Yes, but ALL OVER the official documentation it says running it as a system daemon is not recommended at all. But yes, in the above use case, that would solve the issue of audio not continuing when switching X sessions without needing module-native-protocol-tcp.
> the KDE one
Phonon? Wasn't that just a layer on top of pulse and/or alsa?
Phonon? Wasn't that just a layer on top of pulse and/or alsa?
Had to do a few searches but I found it:
artsd (part of https://en.wikipedia.org/wiki/ARts)
artsd (part of https://en.wikipedia.org/wiki/ARts)
The comments on the bug are exemplary of the kind of crap we deal with when supporting Linux users, and really go a long way towards making people not want to spend any time on these issues.
If you actually read the details you'd note that the code to support ALSA wasn't removed, it was simply put behind a configure option (--enable-alsa). Most of the people complaining in the bug are running builds from a distro that provides Firefox builds, doesn't ship PulseAudio, but didn't bother building Firefox with that option. Their distro shipped them a broken build so of course they come to complain in Bugzilla.
If you actually read the details you'd note that the code to support ALSA wasn't removed, it was simply put behind a configure option (--enable-alsa). Most of the people complaining in the bug are running builds from a distro that provides Firefox builds, doesn't ship PulseAudio, but didn't bother building Firefox with that option. Their distro shipped them a broken build so of course they come to complain in Bugzilla.
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 support, when ALSA is used by less than 1% of users (as seen by the Mozilla hardware survey results), and the work can be used better for the other 99% of users.
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 support, when ALSA is used by less than 1% of users (as seen by the Mozilla hardware survey results), and the work can be used better for the other 99% of users.
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 in years and experience and their time becomes more and more precious.
We used to tell people like these folk "Patches welcome," but then we learned that they give us those patches... and literally never maintain any aspect of them, so now we're stuck supporting their useless, broken, out of date features for years on end.
Worse, some of them come with baked in security vulnerabilities, and still get left on by default because next to nobody knows what it actually does. But we sure as hell get yelled at when we try to remove those broken features - it becomes an uphill battle, every time. We've seen it for Linux device drivers for super obscure hardware, we've seen it for features in desktop applications and entire desktop environments, we're seeing it again in web browsers.
If you aren't using PulseAudio, you have fully accepted that you are willing to be on the fringe <0.01% of Linux installs[1], and so you get to keep all of the pieces of your special configuration. Feel free to maintain your patches out of tree, and stop robbing the vast majority of users progress and the maintainer's time. It's your freedom to have the code and do what you want with it - they don't have to merge it into their code and support you for free. Forks welcome.
Mozilla made the right call. Freedom has a price.
[1]: by measure of software that I maintain on Linux - last I checked less than 100 installs reporting usage information use the non-Pulse backend, albeit I accept those same folk are likely the folk that would disable usage reporting, so we can never know with absolute certainty. I can't imagine Mozilla's numbers are greatly different than what I'm seeing.
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 in years and experience and their time becomes more and more precious.
We used to tell people like these folk "Patches welcome," but then we learned that they give us those patches... and literally never maintain any aspect of them, so now we're stuck supporting their useless, broken, out of date features for years on end.
Worse, some of them come with baked in security vulnerabilities, and still get left on by default because next to nobody knows what it actually does. But we sure as hell get yelled at when we try to remove those broken features - it becomes an uphill battle, every time. We've seen it for Linux device drivers for super obscure hardware, we've seen it for features in desktop applications and entire desktop environments, we're seeing it again in web browsers.
If you aren't using PulseAudio, you have fully accepted that you are willing to be on the fringe <0.01% of Linux installs[1], and so you get to keep all of the pieces of your special configuration. Feel free to maintain your patches out of tree, and stop robbing the vast majority of users progress and the maintainer's time. It's your freedom to have the code and do what you want with it - they don't have to merge it into their code and support you for free. Forks welcome.
Mozilla made the right call. Freedom has a price.
[1]: by measure of software that I maintain on Linux - last I checked less than 100 installs reporting usage information use the non-Pulse backend, albeit I accept those same folk are likely the folk that would disable usage reporting, so we can never know with absolute certainty. I can't imagine Mozilla's numbers are greatly different than what I'm seeing.
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.
> (Especially with their marketshare falling below 8%).
Well when they keep alienating their existing user base by chasing after Chrome's tail, and keep spending effort on marketing in the developing world (shades of SJW meddling/signaling in the management, anyone?), while at the same time seem to treat anything but OSX as second fiddle, yeah their market share will tank, and tank hard.
Well when they keep alienating their existing user base by chasing after Chrome's tail, and keep spending effort on marketing in the developing world (shades of SJW meddling/signaling in the management, anyone?), while at the same time seem to treat anything but OSX as second fiddle, yeah their market share will tank, and tank hard.
> 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%).
What an utterly ridiculous argument. You're implying that everyone using software has to keep track of every single upstream project, their mailing lists and requests. That doesn't even remotely scale on a personal level. There just aren't enough hours in a day to be able to read all those mailing lists, and that's assuming every end user even remotely has the skills to understand what is being discussed anyway.
As an argument, this makes no more sense than "Well it's an open source project, fix it yourself".
This kind of scenario is always going to end up happening.
What an utterly ridiculous argument. You're implying that everyone using software has to keep track of every single upstream project, their mailing lists and requests. That doesn't even remotely scale on a personal level. There just aren't enough hours in a day to be able to read all those mailing lists, and that's assuming every end user even remotely has the skills to understand what is being discussed anyway.
As an argument, this makes no more sense than "Well it's an open source project, fix it yourself".
This kind of scenario is always going to end up happening.
As with anything else, devs only know their own insular world of mailing lists and bug trackers. If it is not showing up on either, it does not exist.
[deleted]
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.
Why is it hard to find a maintainer? I mean, is it just a reflection of Firefox's declining popularity or is there some additional difficulty?
Welcome to the concept of CADT. Everyone is off chasing the latest shiny so they can pad their resume (and maybe do a bit of virtue signaling on the side). Its the same crap that has been going on in the Linux GUI world since the formation of Gnome.
No idea. Is it their own project, or some external one? If the later, the question would be for its developers.
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 likely part of it). It's that PA is not good software. It needs to be fixed. And until it is, you'll have people wanting to go back to software that "just worked".
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 likely part of it). It's that PA is not good software. It needs to be fixed. And until it is, you'll have people wanting to go back to software that "just worked".
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.
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.
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.
No, VFS is a valid kernel interface, as is ALSA. Your analogy is wrong and pointless.
This is more similar to removing all support for files and requiring everyone to install MySQL.
This is more similar to removing all support for files and requiring everyone to install MySQL.
My argument still stands. There is no law against using user-level interfaces and abstractions that wrap those provided by the kernel.
I had a brief panic at just reading ALSA. I haven't used the linux desktop in years, but audio was always such a pain. I hope things have improved.
PulseAudio is pretty good these days and typically works out of the box for most need. Per app volume is an amazing feature and switching sinks is a breeze. I often play music on my stereo (mobo sound card) and game audio on some headphones (audio over hdmi through monitor). Being able to switch them around live is great.
However, like systemd, PulseAudio large and opinionated so it's not everyone's cup-of-tea.
However, like systemd, PulseAudio large and opinionated so it's not everyone's cup-of-tea.
> PulseAudio is pretty good these days and typically works out of the box for most need.
Ehh...... I'll disagree with that. I have ~50% success rate of it working on my devices in the past 5 years.
Ehh...... I'll disagree with that. I have ~50% success rate of it working on my devices in the past 5 years.
A 50% success rate is pretty bad. May I ask what distributions you're using and which devices you've had trouble on? Are you using any special configuration?
Most modern distros come with pulseaudio by default, which means I'd guess that over 90% of linux users use pulseaudio successfully. I've run workshops helping people install linux on their machines and I've never run into a system where pulseaudio did not work that alsa did.
Most modern distros come with pulseaudio by default, which means I'd guess that over 90% of linux users use pulseaudio successfully. I've run workshops helping people install linux on their machines and I've never run into a system where pulseaudio did not work that alsa did.
> come with pulseaudio by default
Which means they almost certainly include libasound.so, because PA still depends on ALSA in the kernel. Even in the case of distros that only use the ALSA emulation interface for PA, the traditional ALSA interface is still provided. Lots of software would break without that support.
It's more accurate to say most distros support both PA and ALSA by default.
> use pulseaudio successfully
Note that "successfully" doesn't imply "enjoyably" or "preferentially". I still hear complaints regularly from people that hate newer (PA-focused) distros that introduced a lot of latency problems. Movie audio sync became inconsistent (hundreds of ms latency, very high variability), and UI audio cues playing up to 3s (3000ms) after the visual changes.
Which means they almost certainly include libasound.so, because PA still depends on ALSA in the kernel. Even in the case of distros that only use the ALSA emulation interface for PA, the traditional ALSA interface is still provided. Lots of software would break without that support.
It's more accurate to say most distros support both PA and ALSA by default.
> use pulseaudio successfully
Note that "successfully" doesn't imply "enjoyably" or "preferentially". I still hear complaints regularly from people that hate newer (PA-focused) distros that introduced a lot of latency problems. Movie audio sync became inconsistent (hundreds of ms latency, very high variability), and UI audio cues playing up to 3s (3000ms) after the visual changes.
Mostly debian and ubuntu. Mostly Thinkpads, a couple of dells that I don't remember the model of, and a couple of compaqs. All of them standard builds. I've never added a soundcard that I can recall.
This is what bothers me so much about discussions about PA. There are legitimate problems with it, and whenever someone mentions them, everyone else chimes in to say that they are the minority, that they are doing it wrong, etc etc. This is how polarization happens.
I've had a much higher success rate with alsa ootb.
This is what bothers me so much about discussions about PA. There are legitimate problems with it, and whenever someone mentions them, everyone else chimes in to say that they are the minority, that they are doing it wrong, etc etc. This is how polarization happens.
I've had a much higher success rate with alsa ootb.
And I have a 100% success rate. A single case don't means nothing.
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)
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...).
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.
I gave up long ago and simply use audio cards that do hardware mixing. There's no need for anything other than ALSA if you do it that way.
Unless you want to do filters or additional in/out channels, and more than the card supports.
In my case, I use 3 audio cards, an internal one for speakers, a Behringer Xenxy Q502 for headphones and microphone, and a backend streaming to my phone (in case I wanna walk around the house listening to music via headphones).
Mixing audio into streams for recording, live stream, headphones, etc isn’t easy even with hardware cards unless you spend a LOT of money.
In my case, I use 3 audio cards, an internal one for speakers, a Behringer Xenxy Q502 for headphones and microphone, and a backend streaming to my phone (in case I wanna walk around the house listening to music via headphones).
Mixing audio into streams for recording, live stream, headphones, etc isn’t easy even with hardware cards unless you spend a LOT of money.
tell me about it ha ha
i think the biggest genius was making a pulseaudio alsa backend so most legacy apps just work
i think the biggest genius was making a pulseaudio alsa backend so most legacy apps just work
On top of the ideological issues I see with things like PulseAudio, it has always given me headaches in practice. I've never had issues with ALSA, but now I need to install an audio server so it can talk to ALSA? These are strange, unfortunate times. I feel linux will eventually succeed at becoming Windows and it makes me sad.
> I've never had issues with ALSA
You haven't been acquainted with asoundrc/dmix/alsamixer. ALSA is to Pulse as XFree86 is to Xorg, I feel no nostalgia for it at all.
You haven't been acquainted with asoundrc/dmix/alsamixer. ALSA is to Pulse as XFree86 is to Xorg, I feel no nostalgia for it at all.
> ALSA is to Pulse as XFree86 is to Xorg, I feel no nostalgia for it at all.
No it is not. X.org is a fork of XFree86. Pulseaudio is a sound daemon built on top of ALSA.
No it is not. X.org is a fork of XFree86. Pulseaudio is a sound daemon built on top of ALSA.
And there are times i wish i could roll back the clock to the XFree86 days. At least then you didn't need to herd a stampede of sub-projects to get a working X11 compiled.
My system had been ALSA-only for many years, until this change forced me to install PulseAudio. About once a week the audio starts crackling and hissing, and I have to restart the Pulse server. Regardless of how old and unmaintained the ALSA backend was in firefox, it worked, and worked well; I never had a single problem with it.
One major factor is security, everything that isn't being actively maintained is passively accumulating exploits.
For example, debian switched from ffmpeg to libav and eventually back to ffmpeg again because the libav maintainers have consistently slow to act on bugs and security holes whereas ffmpeg was anything but despite having a much smaller team looking after it. Debian's own security team called the switch because it is not worth the manpower to maintain both codecs.
For example, debian switched from ffmpeg to libav and eventually back to ffmpeg again because the libav maintainers have consistently slow to act on bugs and security holes whereas ffmpeg was anything but despite having a much smaller team looking after it. Debian's own security team called the switch because it is not worth the manpower to maintain both codecs.
ALSA itself is better maintained than PulseAudio actually.
If they cannot find a developer to maintain ALSA backend, they must really be out of money and skill. Yes, pure ALSA is harder, but not that much harder.
If they cannot find a developer to maintain ALSA backend, they must really be out of money and skill. Yes, pure ALSA is harder, but not that much harder.
> they must really be out of money and skill
A browser dropping below 8% (except for Germany, which is the only country where Firefox is still leading at 43%) surely has different problems than catering to the 1% pure ALSA users of their Linux users, when the Linux users are already 1% of their overall user share.
Especially when funding is dependent on market share...
A browser dropping below 8% (except for Germany, which is the only country where Firefox is still leading at 43%) surely has different problems than catering to the 1% pure ALSA users of their Linux users, when the Linux users are already 1% of their overall user share.
Especially when funding is dependent on market share...
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.
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 me problems (and I'm quick to notice latency, etc. issues).
As someone mentioned elsewhere in the thread, by being an ALSA user you're already in a tiny minority of the Linux world. You might as well be using an OS where your values in are the majority - it's nice to not have to fight against the defaults.
As someone mentioned elsewhere in the thread, by being an ALSA user you're already in a tiny minority of the Linux world. You might as well be using an OS where your values in are the majority - it's nice to not have to fight against the defaults.
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.
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.
It's gotten much easier to both upgrade and to install software. Example:
To apply security patches:
To apply security patches:
freebsd-update fetch
freebsd-update install
freebsd-update -r 11.0-RELEASE upgrade
pkg install chromium
FYI, we're a long time Linux shop (mostly Ubuntu server) and are slowing moving away from it because I don't like the direction it is going (systemd, etc). I've got more than half of our systems on FreeBSD/OpenBSD now.
I agree with pppp - it's quite easy in the most common case. I've run into little problems, but rarely, and certainly no more than what I used to have with Linux.
Hardware support is like Linux a few years ago. That, and a few (esoteric or proprietary) packages that I've found missing are about the only downsides IMO.
FreeBSD has run fine with little to no configuration on all the desktops and servers I've tried, but laptops are a different story. OpenBSD has a better reputation there. My guess (and understand this is based on just my limited perspective) is that the biggest thing to be aware of is video cards (in particular the Intel integrated graphics are one or two generations behind).
Here's the offical word on drivers in general: https://www.freebsd.org/relnotes/CURRENT/hardware/support.ht...
Hardware support is like Linux a few years ago. That, and a few (esoteric or proprietary) packages that I've found missing are about the only downsides IMO.
FreeBSD has run fine with little to no configuration on all the desktops and servers I've tried, but laptops are a different story. OpenBSD has a better reputation there. My guess (and understand this is based on just my limited perspective) is that the biggest thing to be aware of is video cards (in particular the Intel integrated graphics are one or two generations behind).
Here's the offical word on drivers in general: https://www.freebsd.org/relnotes/CURRENT/hardware/support.ht...
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.
It's pretty simple to remove it from SuSE.
That's a relief, I've always liked SuSE.
on arch here. haven't seen the problem yet, and I'm on 52.0. why am I not affected? I don't have pulseaudio installed (only some client libraries. lib32-libpulse, to be precise).
this doesn't look good. thanks for the post.
this doesn't look good. thanks for the post.
you should be fine as arch are compiling their binary with alsa enabled
https://git.archlinux.org/svntogit/packages.git/tree/trunk/P...
line 97 for reference
https://git.archlinux.org/svntogit/packages.git/tree/trunk/P...
line 97 for reference
[deleted]
arch is compiling it with alsa support, but only for a couple more versions.
https://bugs.archlinux.org/task/53195
https://bugs.archlinux.org/task/53195
thanks. this is pretty scary.
guess I'll be using Chromium when that day comes, as I'd rather not run PulseAudio.
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).
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.
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.
While I would agree that we are vastly understaffed, we just don't have the resources to pay people to fix everything. We hire lots of extremely talented developers, but like all software projects everything is a tradeoff. We could pay someone to maintain ALSA support, but that would mean other things would not get fixed. Linux users are already a small fraction of the Firefox userbase (despite most Firefox developers using Linux as their main development environment), so how do we justify spending the resources to maintain an alternate audio backend that's only used by a small fraction of our Linux users? It's not very compelling.
If it is such a problem, why not hide the backend behind a nice library instead of a sound server? Say, off the top of my head, libao (after getting Xiph to fix the license), PortAudio, libsoundio, OpenAL and OpenSL come to mind. There are probably more.
I wish I could. but I don't have the knowledge or the time.
So the guy that has been in office barely 3 years throws his arms up and goes for the latest shiny. More and more i see where JWZ is coming from, though i can't say i share his fondness for Apple products.
I'm in the same boat, Firefox 52 broke ALSA, and Plugins.
I need both. So I'm permanently on 51.
Mozilla: You are making a mistake, revert both of these decisions!
For example see: http://www.kongregate.com/forums/1-kongregate/topics/716510-...
I need both. So I'm permanently on 51.
Mozilla: You are making a mistake, revert both of these decisions!
For example see: http://www.kongregate.com/forums/1-kongregate/topics/716510-...
If you refuse to update, you should at least be on their ESR branch, which is 45. Don't run an insecure, out of date version just because of a single feature.
I gave up on Firefox at the end of last year, and I don't miss it at all. If I hadn't already done it, though, this would've sent me over the edge. (I do not and will never run Pulse on any of my systems.) Currently using a stripped-down version of Chrome, and web browsing has never been better.
Edit: the downvoting on this site is goddamned baffling sometimes. What about my comment has you guys offended today?
Edit: the downvoting on this site is goddamned baffling sometimes. What about my comment has you guys offended today?
What is the stripped-down version of Chrome you use?
Is it something prepackaged or something you've crafted by stripping yourself?
Is it something prepackaged or something you've crafted by stripping yourself?
Currently, Iron browser.
https://www.srware.net/en/software_srware_iron.php
It's gone from "broken on most sites" to "pretty much totally usable" since about October.
https://www.srware.net/en/software_srware_iron.php
It's gone from "broken on most sites" to "pretty much totally usable" since about October.
Maybe Chromium? https://www.chromium.org/Home
It's prepackaged but I kind of lost track how it's different. It used to be that it didn't support flash but that might have changed.
It's prepackaged but I kind of lost track how it's different. It used to be that it didn't support flash but that might have changed.
It doesn't have some plugins or Google login (for bookmark/history sync).
It has Google sync the different is mostly in branding and in some codec support
The linked thread implies that Chrome doesn't support ALSA either. Is that not true?
Chrome supports Alsa and Pulseaudio.
PotterWare(1)
There is real cost to supporting features, and very often, the decision basically amounts to having to choose which feature scarce resources is used for. So you have to be prepared to defend having to divert resources for pet features--keeping in mind that sometimes the other feature is "making sure it builds tomorrow."
From what I can tell, the ALSA backend has been poorly maintained for some time. When the present state of affairs is deficient, and probably retarding code quality in other areas. If it's in a poor state for a long time, it's hard to argue that it is necessary to maintain support--or even that desupporting it will make a huge impact.
If you want to convince me to support something, offering help would be a great start. It could be as little as offering to test and QA a feature, or as much as providing an implementation patch and offering to maintain it for the foreseeable future. Insulting my intelligence and issuing threats for noncompliance are just going to result in me ignoring you, perhaps after laughing at you for a bit.
And remember, if you're not familiar with the relevant code, you're not really qualified to say how hard it is to actually do something. Code architectures may not be implemented the way you expect them to be, so what seems like it should be an obvious minor feature may turn out to require thousands of lines of changes (that was exactly how my first open source contribution turned out--what I thought should have been a five-line patch or so was really 1000 or so lines of changes).