Re: Pulseaudio

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

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

OK, I see a fork() call in the source code.  You're right.  There's only
one minor difference here which is that dmix uses shared memory, while
esd uses unix socket.  No idea about PA.

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

Except hardware mixing.  Except clickless audio.

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

If what you say above about forking is true, then I definitely am using
hardware mixing ("VIA High Definition Audio Controller (rev 10)", though
this is not the same harware I tried PA on, the one that produced audio
clicks).

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

I thought real-time required root privs or a suid root daemon...

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

I do.  Yet another "feature" I don't need and which was getting in the
way of perfect sound, so I just disabled it.

> 
> > > 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.
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
"The universe is always one step beyond logic" -- Frank Herbert