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

[Morgan Gangwere]

On Mon, 29 Nov 2010 07:28:45 +0800
Ng Oon-Ee <ngoonee at gmail.com> wrote:

> > - It's unstable.
> > - 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.
> 
> Where you've mentioned specific bugs below I'll answer. Otherwise this
> is just FUD generalization. And pulseaudio is not unstable just because
> an implementation in ANOTHER distro YEARS ago caused some problems.

What Yaro said was not a generalization, or even FUD. It was intended to be a statement of opinion, based on scientific theory of "If A works, and B doesn't, B must have problems"

Plus, look at all the Ubuntu and RedHat folks who ask "How, How do I remove this beast of a pile from my system?"
 
> > - It wastes a lot of RAM.
> > - It wastes a lot of CPU.
> > - It causes noticeable audio latency.
> 
> RAM and CPU usage never appear on top 5 on my system. Its at 2% of CPU
> and 0.3% of RAM (4 GB) here on top. And synchronization of movie audio
> is perfect here (even when outputting at the same time to multiple sound
> cards, including a BT headset, try that with alsa)

Yeah, you aren't running on REALLY low end hardware. Try my box: a 700Mhz P3 Coppermine chip with 240MB of RAM open to the kernel. PA is a pile on that machine, and doesn't understand the ESS Maestro3i chip that's in it. ALSA when run through alsaconf... DOES!

Start using REALLY low-end hardware and stop using flat top.

As for multiple sound cards? Not a problem. I consistantly go between a USB headset and a full speaker system. How? Oh i don't know, by telling the app I want to talk to to talk to hw:1,0 instead of hw:0,0? Something like that.

ALSA is a magificent Pile of steaming shit. Its just not as gold-covered as PA.

> > - 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.
> 
> nedko (jack2) and the Pulseaudio devs specifically worked on such
> support. Just because you are ignorant of it does not make it not exist.
> As correctly pointed out though, jack2 is a separate implementation of
> jack from jack1, jack1 does not support notifying pulseaudio about its
> 'claim' on the soundcard. There's 2 players here, not just one.

That's a deeper, fundamental problem with the sound on Linux. Five different daemons do NOT need to be implemented just to do SOUND anymore. I think that's what Yaro is trying to get at.

> > - 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.
> 
> The ONLY major ALSA 'feature' which is not supported is memmap. Direct
> access to the sound-card's memory. Pulseaudio's devs are of the opinion
> that this cannot and should not be emulated, and that apps which use it
> are broken in design. I've not come across any latest-version-apps where
> this is still a problem, do you know of any?

You're going to go rally hardware vendors, right? What about my ESS Maestro3i? *the damn thing needs firmware* and its a *right bitch* to get working. Oh and did I mention on my other box the Realtek chipset needs to be told what it can output "Front" to? THis is a non-issue when it comes to comparing PA to ALSA. Blame vendors for being total shitheads. until then, there's a quite nice reason to emulate some hardware memmapping.

As for apps that need it, I know a few. Quake, as well as some virtualization systems, really like having it because it makes their life Easier. SDLQuake relies on ALSA to do this, as well, and uses quite a bit of hardware memory because its CHEAPER. 

And ALSA has way more features not supported, for example this magical idea of "switches" -- You know, those things that fiddle bits in some keep-alive packet to the hardware that say "I want this to be like this".

yes, I have to use switches.

> > - Even the Pulse Audio devs at one point admitted it breaks Linux audio.
> 
> Context, please. Quotation if possible. The only similar statement I
> remember is Lennart saying (more than a year ago) that it would break
> audio apps which rely on alsa hacks (most apps AT THE TIME). Which would
> mean that these apps need fixing.

You don't read through RH's bugtracker for PA do you? 

> If you think 'oh, what works before must be great code', I'm sure you'd
> be one of the first to protest (for example) Wayland on the grounds that
> X11 works just fine.

I'll protest Wayland because its Yet Another Thing To Change The World Coming Out Of RedHat. Oh, and that my computers don't all have full 3D glx acceleration. Really! they don't. 

> > - A great deal of Linux applications have problems working with it, far
> > 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.
> 
> See above. You do not understand what is being done, nor have you made
> an attempt to. Pick up the latest Ubuntu liveCD, run it on almost any
> system you want. Sound will 'just work (tm)'. And they get all those
> nice features which they can CHOOSE to use or not. Your complaining is 2
> years too late, because linux apps NOW support pulseaudio just fine.
> mplayer, vlc, mpd, wine, sdl, gstreamer et. al. The only sort of apps
> which still don't have good PA support are audio editing apps which are
> more meant for use with Jack (ardour and audacity for example).

Actually...

the latest ubuntu (10.10) segfaults on 3 of my boxes. I haven't used Ubuntu since a futex() bug that they introduced would cause random lockups during Mutex interactions in single-threaded applications. Yes there's a case where you want to use a mutex in a single threaded application, primarily if you're using shared memory.

I try playing Quake(2) on PA and I get laggy audio, poor performance (it brings my load up past 10!) and generally REALLY BAD results. PA brings when IDLING my load up to at least 2-3 when I'm on a P3 700Mhz coppermine chip.

As someone who regularly calls most of the linux community the "Linux Children", I feel that its appropriate now. With each new Big Thing, its assumed you're using the best damn computer on the face of the planet. When FreeSWAN was doing its development, you know how they found memory leaks? they loaded it on a 200Mhz box with 8MB of ram. Memory leaks of BYTES each were found.

As well, Pulse still doesn't work on my Alienware laptop. Realtek chipset, hda_intel picks it up as being generic. things almost work, except headphones. PA will only let sound go through the front speakers, while ALSA just has a switch. Its a known WONTFIX bug, too.
 
> > - An incredible array of utterly useless features (Like networking sound
> > in a day and age where all PCs have sound systems they can use
> > themselves. Never count on networking where an actual local system will
> > do.) that Pulse Audio fans never use bt love to brag about so they can
> > distract from Pulse Audio's obvious problems, just like you are doing
> > right now.
> 
> Yes, you don't use a feature so its utterly useless. Good point! And its
> not like that's the ONLY feature available to pulseaudio.
> 

Honestly, I think what he was trying to get at is there are much more UNIX-flavored ways to do this.

ALSA, OSS, even at one point (And I know I'll get criticism for this) yiff-server[0] get this right.

[0] http://packages.debian.org/source/squeeze/yiff

-- 
Morgan Gangwere <0.fractalus at gmail.com>

PUNY DISCLAIMER: I'm my own person. I make misteaks. Please, remember this.

Debian to Arch convert. indrora on IRC.