Re: Pulseaudio

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote:
> <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.

You are mistaken.  ALSA dmix does not require any daemon.  I suspect  it
uses SYSV IPC to make all processes do some kind of distributed mixing,
with no daemon required.


> 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).

Even if dmix is buggy, why can't it be fixed instead.

And not to mention that even my desktop PC with ultra cheap motherboard
has builtin sound which supports hardware mixing.  I am pretty sure I'm
not using any kind of software mixing at the moment: neither dmix nor
esd nor pulseaudio.  I just think that, by default, users should be
given a chance to experience audio with hardware mixing, if the hardware
supports it.

But most importantly, I wouldn't mind PulseAudio too much *if it worked
correctly*.  As it is now, maybe it isn't PA's fault, maybe it's the
linux kernel's fault for not having a good enough process scheduler, but
the sad truth is that PA's sound skips (I mean I hear audio clicks when
switching workspaces).  I believe when people say it doesn't skip for
their hardware, but I expect people to believe me when I say it does
skip for me.

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

Those are nice features, but all summed together they don't come near to
"skipless sound" that raw ALSA provides.

>   * Decent OSS emulation that doesn't cut software-mixing out of the loop

OSS is deprecated.

>   * Drop in esd replacement for backwards compatibility.

I already do not use esd.

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

That should be an extra layer *on top of* basic sound, not a replacement
layer.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
"The universe is always one step beyond logic" -- Frank Herbert