Some pulseaudio questions...

[Lennart Poettering]

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

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

The longer story goes like this:

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, i.e. all
other programs would have to share what is remaining and would have to
swap all the time. Given that PA is just an auxiliary tool and not the
main reason people run computers this is hence not an option. Due to
that PA doesn't use mlock()/mlockall() like textbooks suggest, and it
never did.

Now, just ignoring the whole locking issue is also not an option. So I
tried to find a compromise: try my best to make sure that the data
accessed by the RT threads is available in memory but ignore the rest
of the memory. To achieve that I needed a way to safely swap in memory
when *I* need it to instead of letting the kernel to do as it as late
as possible. Then, whenever the non-RT threads in PA pass off data to
the RT threads I first swap the data in explicitly. That way I hope
that the RT threads never need to wait for swapping in and can
continue to loop in their little loops and continue to do whatever
else they might want to do, but not wait for disks spinning.

There is a system call for requesting swapping in of memory:
posix_madvise(POSIX_MADV_WILLNEED). A few kernel releases ago this
didn't work for anonymous memory, only for file-backed memory. (But on
my request this was then changed in the kernel). Now, to support older
kernels I added a dirty dirty hack: I try to lock those pages into
memory and then unlock them right away, which should have about the
same effect as the madvise() call. On current kernels that mlock() is
never tried however, because WILLNEEED works fine anyway. And it's a
horrible hack. And I probably should remove this from PA now.

> I'll admit I'm about ready to hack in some horrible mlockall hacks to
> see if that'll stop the poppy/skippyness on this box.

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. To work around that you could try
disabling timer-based scheduling mode and revert to sound card IRQ
scheduled playback. For that try passing "tsched=0" to
module-hal-detect in /etc/pulse/default.pa. Then restart PA. Another
issue might be that PA does not actually get scheduled often enough
by the kernel. Might be caused by a bad driver (nvidia closed
source). You can run PA as RT if you wish (which we hopfully will be
able to enable by default in F12). For that increase RLIMIT_RTPRIO to
10 or so in /etc/security/limits.conf and login again.

Usually running "pulseaudio -vvvvv" in a terminal might give you a
hint what might be going wrong.

Lennart

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