3 ms·

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% CP

by 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
  Thanks, that's a definite win for pulseaudio and I hadn't really considered the developer side of it at all (I'm primarily backend/network/db). I certainly don't think pulseaudio is an inherently bad architecture, but I do feel it's matured too slowly in terms of stability. On the flip side as you it's more user-friendly than Network Audio Server (which has fewer features) and and as you point out supports more of the "I've got an hdmi output playing music through my tv, but a bluetooth headset for voip" use cases that a decent-sized class of users run into. It also occurs to me for the first time that the rise of pulseaudio was not that many years after laptops largely switched to integrated codec chips instead of discrete sound and I had all sorts of problems with those above and beyond the "Damn it, give me hardware volume controls" frustrations. It could have inherited some of the problems around quirky/flaky hardware that I remember ALSA facing in that period. At this point I just want something that can reliably play music or take audio input and for whatever reason pulseaudio isn't it for me. Hopefully that'll change before most distros switch to whatever the new hotness in sound setups is...

by pyre 13y ago

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
Thanks, that's a definite win for pulseaudio and I hadn't really considered the developer side of it at all (I'm primarily backend/network/db). I certainly don't think pulseaudio is an inherently bad architecture, but I do feel it's matured too slowly in terms of stability. On the flip side as you it's more user-friendly than Network Audio Server (which has fewer features) and and as you point out supports more of the "I've got an hdmi output playing music through my tv, but a bluetooth headset for voip" use cases that a decent-sized class of users run into. It also occurs to me for the first time that the rise of pulseaudio was not that many years after laptops largely switched to integrated codec chips instead of discrete sound and I had all sorts of problems with those above and beyond the "Damn it, give me hardware volume controls" frustrations. It could have inherited some of the problems around quirky/flaky hardware that I remember ALSA facing in that period. At this point I just want something that can reliably play music or take audio input and for whatever reason pulseaudio isn't it for me. Hopefully that'll change before most distros switch to whatever the new hotness in sound setups is...