Re: Pulseaudio

[Jan Schmidt <thaytan mad scientist com>]

<quote who="Gustavo J. A. M. Carneiro">

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

The first process to open the sound device is forked in alsalib and
*becomes* the dmix mixing daemon. Check it out in your ps listings.
All the other programs requiring access to mixing services then deliver
their streams to that process via a shared memory mapping. It ends up being
fundamentally the same as pulseaudio or esd with autolaunching.

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

By separating the dmix piece from alsalib, I believe we can do better and
provide more.

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

I think you are most likely wrong here. Every motherboard I've seen in the
past 4 years with built-in sound has used AC97 with a codec chip, and none
of them have provided hardware mixing support. You're probably using dmix
and just don't realise.

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

The most likely reason is that you need to give pulseaudio the ability to
acquire real-time scheduling privileges, like you do for jackd, because it
operates with smaller hardware buffers to achieve lower latency. On a distro
that provides PulseAudio integrated, this should happen by default.

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

See the real-time privs point above, or modify the PA config to have bigger
buffers.

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

There are plenty of apps that use it though. That may not matter to you, but
backward compatibility is important.

> >   * Drop in esd replacement for backwards compatibility.
> 
> I already do not use esd.

You must have the Gnome desktop sounds turned off then.

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

If you want to do it so that the apps don't have to know about it, it has to
integrate underneath them somewhere. But again, I don't see this as PA's
major appeal, it's just a neat side-benefit of building things this way.

Jan.