Re: Pulseaudio

[Jan Schmidt <thaytan mad scientist com>]

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

> 
> On Thu, 2007-10-11 at 23:28 +1000, Jan Schmidt wrote:
> > <quote who="Gustavo J. A. M. Carneiro">
> > 
> > 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.

PA uses shared memory segments by default.

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

PA currently doesn't pass streams through to hardware that supports mixing,
I think. There has been talk about having it do so though, and there's no
reason why a separate daemon can't provide that.

Are you still unclear on the 2 options for making PulseAudio click-free?
Either increase the hardware buffers it uses so that it acts like ALSA, or
set it up so it can get real-time privs.

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

That may be (regarding hardware mixing). Google isn't being helpful in finding 
me information about that controller and how many input streams it supports.

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

Yes, that's the general case, and the way (for example) Jack does it too.
Both Jackd and PA are very careful to drop the root privilege first thing on
startup. Nevertheless, even that is no longer necessary - on recent kernels,
non-root daemons can be configured to be allowed RT privileges using
rtlimits/PAM [1]

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

I turn it off because I find most of the desktop sounds annoying, but I
still want the feature to work with whatever solution we end up with, and as
you point out - it doesn't at the moment.

Jan

[1] http://lau.linuxaudio.org/faq/index.php/Capabilities