Some pulseaudio questions...

[Jon Masters]

On Fri, 2009-06-05 at 12:57 +0200, Lennart Poettering wrote:
> 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.

I noticed :) But then, neither is the posix_madvise being used that much
either, as I noted. On a related note, I have revived the upstream
discussion of MCL_INHERIT and will repost patches implementing this over
the weekend - then I can have a simple wrapper utility to test forcing
an app like PA to do an mlockall.

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

> There is a system call for requesting swapping in of memory:
> posix_madvise(POSIX_MADV_WILLNEED).

Yeah, I saw that and I think it's a nice idea. I'm not sure it's being
called very often though - bear in mind I only spent a few minutes
looking at the source, so I might have missed something.

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

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.

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

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

I will try that.

> Then restart PA. Another issue might be that PA does not actually
> get scheduled often enough by the kernel.

I don't think it's that. There's no closed source driver installed. I
also am currently running PA as an RT task and my SMI detector shows
that this box is not disappearing off into SMI land too often.

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

Not very much useful output when I set it into a debug loglevel - maybe
this is different.

Jon.