5 ms·

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

by 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.
- sdkmvx 10y ago
  > 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.
  - khedoros1 10y ago
    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.

by onli 10y ago

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