[arch-general] Opinions on pulseaudio [WAS: PulseAudio in [testing]]

[Philipp Überbacher]

Excerpts from Rasmus Steinke's message of 2010-11-28 18:00:52 +0100:
> Let me answer on your points...
> 
> > Fine, Then I'll list all of its problems right here:
> >
> > - It's unstable.
> NEVER crashed on me...
>From the PA page:
"Current Status
The PulseAudio daemon and utilities are still under heavy development.
Although they are generally considered stable, they haven't seen enough
testing to warrant a first completely stable release."
> > - It's got far too many unresolved bugs the upstream developers defer
> > INCORRECTLY elsewhere simply because they can't be bothered to fix their
> > software.
> Possible, tho i did not experience any...
> > - It wastes a lot of RAM.
> never see it in top.
It shouldn't, PA is also to a large degree developed for mobile phones.
> > - It wastes a lot of CPU.
> see above. In fact it uses LESS cpu then pure alsa does here, since alsa 
> is resampling everything, altho my card can natively play all 
> samplerates. Pulse behaves correctly here and simply routes it forward.
I'm rather sure PA resamples everything and with alsa it depends on the
configuration. They might use different algorithms by default.
> > - It causes noticeable audio latency.
> You cant be serious? i have been using pulse audio over network from one 
> room to the next. It synced audio with my movies 100% even over a slow 
> wifi network. This would never work with high latency audio backends...
Low-latency is no goal of PA, its latency might change at any time or
all the time, it simply doesn't matter for the use cases it is designed
for.
> > - It DOES NOT release sound to other daemons as your erroneously claim.
> > It will not turn itself off for JACK just as it won't turn itself off
> > for ESD or Phonon.
> > - It actually doesn't support ALSA that well, it's ALSA module is stuck
> > at 70% completion, with a lot of critical ALSA support stuck on that
> > missing 30%. Again, further upstream blame gets laid on ALSA or drivers
> > where it doesn't belong.
> I am actually not too sure about this one, since upstream alsa DOES have 
> a lot of bugs that never get fixed.
> > - It's not really necessary for any actual Linux audio needs, where
> > things like ESD and Phonon had already fixed the problems Pulse Audio
> > has no use for.
> Phonon has solved what exactly? Its totally useless overhead with not a 
> single complete backend. Every single backend is missing features the 
> other one has.
> > - Even the Pulse Audio devs at one point admitted it breaks Linux audio.
> > - A great deal of Linux applications have problems working with it, far
> You can simply forward alsa AS IS to pulseaudio - this should work for 
> about any software you can think about. Btw: skype works much better 
> with pulse than with alsa. i know, bad example, but still.
It should, but apparently doesn't. From what I read in this thread xine
and apparently also mplayer (an mplayer update tries to pull libpulse)
are fine examples. This probably is due to incomplete 'libalsa pulse',
the part of PA that is supposed to imitate the alsa.
> > more than any other daemon to date. Upstream, rather than making Pulse
> > Audio abstract itself like ESD or Phonon does, seems to want app
> > developers to write their code SPECIFICALLY for Pulse Audio, which is
> > NOT how its done.
> actually it is. mplayer, mpd, clementine <insert some audio software 
> here>, all have native pulse audio backends. And those are normally used 
> by people with small WMs, not gnome users.
Not long ago Lennart urged developers not to use the PA API. That may
have changed now, but I guess this is because people didn't listen and
he was under pressure not to change the API. Anyway, if PA really worked
that well and could emulate alsa and everything else as it should then
why would the PA API be used at all?

One PA to rule them all, One PA to find them,
One PA to bring them all and in the darkness bind them

> > - An incredible array of utterly useless features (Like networking sound
> > in a day and age where all PCs have sound systems they can use
> See above. I know several people (also on arch) that use pulse audio 
> with mpd, since its the easiest way to control mpd remotely AND have 
> sound locally.