Some pulseaudio questions...

[Lennart Poettering]

On Fri, 05.06.09 11:11, Jon Masters (jonathan at jonmasters.org) wrote:

> > > Anyone want to clarify my understanding of PA's use of
> > > mlock/posix_madvise? From looking over the code - in particular
> > > pa_will_need, and its callsites - it looks like PA doesn't really use
> > > this support that it has for locking pages. Which seems weird.
> > 
> > mlock() is not actually used anymore by PA on modern kernels.
> 
> I noticed :) But then, neither is the posix_madvise being used that much
> either, as I noted. 

Yes, that is true. We primarily use that when playing samples from the
cache, since the sample cache has a very high and obvious probability
to be swapped out. We probably should place these calls at other
strategic points.

> > Text book RT applications use mlock()/mlockall() to lock themselves
> > into memory and make sure they never are swapped out. This is
> > something we cannot really do for PA given that map a *lot* of stuff
> > into our address space: libraries, SHM segments for communications
> > with other clients, cached samples, and so on. If we'd lock all that
> > into memory there wouldn't be any memory left for much else
> 
> Yeah, I'm aware of this. But there perhaps should be some option anyway
> - after all, you already have all the support code for it, and already
> handle setting real time priorities too. In my brief time with a hacked
> up local build that does an mlockall right at the beginning of the
> mainloop, I am hearing few audio pops and skips on this box. It's
> obviously not a longer term solution, just a datapoint.

Hmm, interesting. You really say mlockall() has a big effect?

An option to use mlockall certainly does make sense. I have added
that now to PA git in commit a9b38b35.

> It did drastically reduce it. The box is under extremely heavy stress as
> it's running a lot of stuff - dozens of firefox, many evolution windows,
> IRC, rhythmbox, a few VMs, etc. I'm looking forward to the IO Controller
> patches so I can e.g. prevent evolution from hogging more than a certain
> amount of disk bandwidth, which I'm sure will help.

What would be good to have would be a "swap niceness" value that could
be attached to a processes or memory regions. i.e. some way to
influence the swapping algorithm in a less binary way than just "swap
this" or "don't swap this".

> > I doubt that locking PA into memory will fix your issues. If PA drops
> > out often this might have various reasons, but probably not
> > swapping. Often the timing calls of your sound driver are inaccurate
> > and cause PA to miss its deadlines.
> 
> The Intel HDA driver on here doesn't appear to be in your badlist any
> more, but maybe I am wrong:
> 
> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
> Definition Audio Controller (rev 02)

The actualy codec used is more interesting. The codec is shown at the
top of the 'alsamixer' screen.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4