4 ms·

Wasn't looking forward to this "upgrade" ... The fact that it's from the same dude as PulseAudio is enough to make me anxious, the pulseaudio stuff didn't go sm

Wasn't looking forward to this "upgrade" ... The fact that it's from the same dude as PulseAudio is enough to make me anxious, the pulseaudio stuff didn't go smooth. (I'm still of ALSA, yes also is a mess to.) So I hope I won't be forced, to a more crappy system ! The fact that it will be handling a lot of stuff more, sounds like a major pita ...

pyre 13y ago
| the pulseaudio stuff didn't go smooth That wasn't the fault of the developer so much as it was the fault of the distributions for jumping on the bandwagon (making it the default audio system) too early.
- nieve 13y ago
  Poettering oversold its state of stability and then seems to have largely lost interest during the most critical period of adoption. The distributions are responsible for believing the hype and shipping too early, but that doesn't change the fact that the developers were hyping it well beyond what was justified. PulseAudio has a lot of nice features, but it's still less stable and has more bizarre failure modes for me _9 years_ after its initial release than plain old ALSA. I literally know no other linux users who have ever had anything good to say about PulseAudio. Entirely anecdotal, but when it comes to trusting developers to do a good job in the first place, much less help with a major transition I'm not inclined to discount that.
  - pyre 13y ago
    After the initial transition period, I have not had any PulseAudio issues other than on maybe 2 occasions where the pulseaudio daemon ran amok, consuming 99% CPU for some reason, until it was killed. I'll admit that I'm not running any exotic configurations though, but built-in audio works just fine, and plugging my USB camera/microphone[1] has worked without issue for a long time too. At one point I was also able to stream audio from my HTPC to my laptop, so that I could use my headphones when everyone else was sleeping. Though I'll admit configuration was a pain in the ass, I don't recall being able to do that with ALSA (though I recall someone creating a shell script a while back that read from /dev/dsp and piped to a socket). Prior to PulseAudio, sound on Linux was always an uphill battle for me (don't get me started on regressions in the PowerBook audio driver that no one cared about since "it works on the newer PowerMacs"). It was a crap-shoot which audio system an application would use. OSS? Alsa? eSound? KDE's sound daemon? Do they all use the same mixer app? What happens when I write to /dev/dsp? Does all other audio block? Which applications support Jackd? etc... [1] Referring to the mic in the pulseaudio context. EDIT: > I literally know no other linux users who > have ever had anything good to say about > PulseAudio. I'll mention that the same could be said of OSS or ALSA too. They may have worked better for you, but I doubt that prior to PulseAudio, you were singing their praises from the rooftops.
    - nieve 13y ago
      Oh, I definitely wasn't singing their praises even if ALSA was a step up from OSS, PulseAudio was just a new low for me in sound systems. My biggest frustration with it was the tendency it's always had on my systems to simply stop producing sound with no obvious cause and when it was working block anything that didn't use it from producing sound. Sometimes a random process had either accidentally muted everything or triggered a bug that did so, other times audio would get sent off to some completely useless sink, occasionally there were no noticeable causes and you just had to kill and restart the daemon (if you were lucky). On top of that a lot of choices were made that tended to bind it to one console, so switching to another would cut out all sound. I guess my core complaint is that ALSA could be a pain to get working properly on a new system, but once it was working it didn't usually spontaneously break on me. PulseAudio was only slightly more likely to work out of the box, but was much more likely to break without my making any changes. I guess it's partially a sysadmin mindset, but I usually come down on the side of preferring up-front pain to long term unreliability. Perhaps I didn't use as wide a set of audio programs as you did, I didn't tend to run as many of them at once, or my hardware just had better drivers. For streaming sound (I didn't care about video) I usually stuck to network servers that could shove audio down a Shoutcast or http stream and listening with something like Amarok or MPD, I'm sure PA was nicer if you were trying to relay what your HTPC was playing back. [ETA: I use linux consoles very heavily when I'm coding on a linux machine, I know this isn't exactly the most common behavior among more recent unix users.]
    - zanny 13y ago
      It's the difference between a sound server and having kernel audio device APIs. Pulseaudio is an actual daemon running that is sinking audio and managing it in realtime - ALSA (sans dmix, and piling other alsa plugins on top of that) was just an API into the kernel audio interface. Sound servers are a modern, I'd argue, necessary convenience for the average joe. API wise, pulse is much nicer to use than alsa (pcm_sink_thing_getbuffer_readhardware_processpcm() x50. I've debugged the sdl implementations of alsa and pulse, and pulseaudio literally takes a tenth the code to use).
      - nieve 13y ago
Qantourisc 13y ago
Thanks all for the feedback ! Have a little more trust in systemd now... still anxious about it being a single blob :)
- bkor 13y ago
  Suggest to read the previous articles by this Debian person (a comment on HN linked to the other ones). He wrote a document explaining that systemd is different daemons, utilities, etc. Further, some stuff is only done after forking (minimizing the impact a crash could have).

pyre 13y ago

| the pulseaudio stuff didn't go smooth That wasn't the fault of the developer so much as it was the fault of the distributions for jumping on the bandwagon (making it the default audio system) too early.

nieve 13y ago
Poettering oversold its state of stability and then seems to have largely lost interest during the most critical period of adoption. The distributions are responsible for believing the hype and shipping too early, but that doesn't change the fact that the developers were hyping it well beyond what was justified. PulseAudio has a lot of nice features, but it's still less stable and has more bizarre failure modes for me _9 years_ after its initial release than plain old ALSA. I literally know no other linux users who have ever had anything good to say about PulseAudio. Entirely anecdotal, but when it comes to trusting developers to do a good job in the first place, much less help with a major transition I'm not inclined to discount that.
- pyre 13y ago
  After the initial transition period, I have not had any PulseAudio issues other than on maybe 2 occasions where the pulseaudio daemon ran amok, consuming 99% CPU for some reason, until it was killed. I'll admit that I'm not running any exotic configurations though, but built-in audio works just fine, and plugging my USB camera/microphone[1] has worked without issue for a long time too. At one point I was also able to stream audio from my HTPC to my laptop, so that I could use my headphones when everyone else was sleeping. Though I'll admit configuration was a pain in the ass, I don't recall being able to do that with ALSA (though I recall someone creating a shell script a while back that read from /dev/dsp and piped to a socket). Prior to PulseAudio, sound on Linux was always an uphill battle for me (don't get me started on regressions in the PowerBook audio driver that no one cared about since "it works on the newer PowerMacs"). It was a crap-shoot which audio system an application would use. OSS? Alsa? eSound? KDE's sound daemon? Do they all use the same mixer app? What happens when I write to /dev/dsp? Does all other audio block? Which applications support Jackd? etc... [1] Referring to the mic in the pulseaudio context. EDIT: > I literally know no other linux users who > have ever had anything good to say about > PulseAudio. I'll mention that the same could be said of OSS or ALSA too. They may have worked better for you, but I doubt that prior to PulseAudio, you were singing their praises from the rooftops.
  - nieve 13y ago
    Oh, I definitely wasn't singing their praises even if ALSA was a step up from OSS, PulseAudio was just a new low for me in sound systems. My biggest frustration with it was the tendency it's always had on my systems to simply stop producing sound with no obvious cause and when it was working block anything that didn't use it from producing sound. Sometimes a random process had either accidentally muted everything or triggered a bug that did so, other times audio would get sent off to some completely useless sink, occasionally there were no noticeable causes and you just had to kill and restart the daemon (if you were lucky). On top of that a lot of choices were made that tended to bind it to one console, so switching to another would cut out all sound. I guess my core complaint is that ALSA could be a pain to get working properly on a new system, but once it was working it didn't usually spontaneously break on me. PulseAudio was only slightly more likely to work out of the box, but was much more likely to break without my making any changes. I guess it's partially a sysadmin mindset, but I usually come down on the side of preferring up-front pain to long term unreliability. Perhaps I didn't use as wide a set of audio programs as you did, I didn't tend to run as many of them at once, or my hardware just had better drivers. For streaming sound (I didn't care about video) I usually stuck to network servers that could shove audio down a Shoutcast or http stream and listening with something like Amarok or MPD, I'm sure PA was nicer if you were trying to relay what your HTPC was playing back. [ETA: I use linux consoles very heavily when I'm coding on a linux machine, I know this isn't exactly the most common behavior among more recent unix users.]
  - zanny 13y ago
    It's the difference between a sound server and having kernel audio device APIs. Pulseaudio is an actual daemon running that is sinking audio and managing it in realtime - ALSA (sans dmix, and piling other alsa plugins on top of that) was just an API into the kernel audio interface. Sound servers are a modern, I'd argue, necessary convenience for the average joe. API wise, pulse is much nicer to use than alsa (pcm_sink_thing_getbuffer_readhardware_processpcm() x50. I've debugged the sdl implementations of alsa and pulse, and pulseaudio literally takes a tenth the code to use).
    - nieve 13y ago

Qantourisc 13y ago

Thanks all for the feedback ! Have a little more trust in systemd now... still anxious about it being a single blob :)

bkor 13y ago
Suggest to read the previous articles by this Debian person (a comment on HN linked to the other ones). He wrote a document explaining that systemd is different daemons, utilities, etc. Further, some stuff is only done after forking (minimizing the impact a crash could have).