3 ms·

Poettering oversold its state of stability and then seems to have largely lost interest during the most critical period of adoption. The distributions are resp

by 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

by nieve 13y ago

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