5 ms·

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 fa

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.

onli 10y ago
> 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 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.
- scrollaway 10y ago
  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".
  - minitech 10y ago
    > "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.
    - AstralStorm 10y ago
      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.
stonogo 10y ago
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.
- scrollaway 10y ago
  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?
  - stonogo 10y ago
    > 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.
Sanddancer 10y ago
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.
- cjhanks 10y ago
  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.

onli 10y ago

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

scrollaway 10y ago
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".
- minitech 10y ago
  > "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.
  - AstralStorm 10y ago
    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.

stonogo 10y ago

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.

scrollaway 10y ago
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?
- stonogo 10y ago
  > 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.

Sanddancer 10y ago

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.

cjhanks 10y ago
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.