Re: Pulseaudio



<quote who="Ronald S. Bultje">

>    Daemons for sound routing are not just suboptimal, they are wrong. We have
>    better ways (at least on Linux) nowadays. Any solution based on the idea
>    of a userspace daemon is wrong. Not just suboptimal (which is
>    unacceptable, because ALSA directly is - for Linux users - very much so
>    optimal, and that's 90% of your userbase), not just "still somewhat
>    acceptable" (because it isn't, we've ditched esound for that very reason)
>    and definitely not "required because a small subgroup of your user
>    population needs it" (crippling for the sake of network users - yeah
>    right).

I get so sick of people saying "but I don't *want* a sound daemon, ALSA can
do it all!". It's so irritating because ALSA's solution for mixing on the
vast majority of modern sound hardware is to have to use dmix, and *dmix is
a sound daemon* - it's fundamentally doing *exactly* the same thing that
pulseaudio does, except that it forks whichever process happens to open the
audio device first instead of being an explicit separate binary.

Plus, it traditionally hasn't even done a very good job of being a sound
mixer. It does crappy resampling, gives poor feedback on the number of
unplayed samples and drops out just as much as a normal sound daemon because
it's just a process with normal privileges - all problems that PulseAudio
doesn't have when configured correctly (configured so that it can obtain
realtime privs, that is).

And of course there's the things the PA can do that bare ALSA never will:
  * Sample caching
  * Low latency per-process volume control.
  * Graceful handling and policy for on-the-fly device removal and insertion
  * Decent OSS emulation that doesn't cut software-mixing out of the loop
  * Drop in esd replacement for backwards compatibility.

And last, and actually one of the minor features: networked audio.

Jan.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]