Re: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R, system performance down!

From: Will Dyson <will.dyson@email-addr-hidden>
Date: Mon Feb 13 2006 - 03:18:10 EET

On 2/12/06, Ismael Valladolid Torres <ivalladt@email-addr-hidden> wrote:
> I just compiled a vanilla kernel 2.6.15.4 in my G3 powerpc. Also I
> compiled, installed and loaded the realtime-lsm module and I started
> to play with jackd -R and some jack enabled applications.
>
> If I start jackd without realtime, everything runs nicely, of course
> with some xruns when I switch windows, manipulate GUIs and such. This
> is more or less what I expected.
>
> But then I run jackd realtime using qjackctl. I start amsynth and it
> takes a bit longer to load but then runs without a mess. Sound is
> clean, no artifacts, no xruns.
>
> Then I try horgand. It takes a lot for it to load, then it sounds
> nicely, I get no xruns, but my X Window system becomes unresponsive.

How much memory does your machine have? Is it swapping when this
slowdown occurs?

By default, realtime mode will cause all jack applications to
mlockall(). This means that large GUI toolkits such as QT (and all
other libraries used by the app) are locked into memory, potentially
forcing the kernel to swap out other important programs (like the X
server). Try the "Unlock Memory" and "No Memory Lock" options (in that
order) in qjackctl.

If those options cause you to start seeing Xruns again, you may simply
not have enough memory in your system for the set of apps you want to
run.

Digression and thread jack follows.

Ideally, realtime audio apps would be written such that:

1. The realtime audio thread(s) are as independant of the GUI as possible.

2. Only the code and data actually needed by those threads would be mlock()ed.

I think most jack apps are already written such that 1 is true, and it
should not be too hard to selectivly mlock() the data buffers used in
the realtime thread. But I don't know how to tell the Linux kernel to
mlock() only the code pages used by a certain thread. Doing that
automaticly seems like a rather hairy technical problem (it may even
be equivalent to solving the halting problem, i.e. impossible).

http://en.wikipedia.org/wiki/Halting_problem

Even given that a programmer performs static analysis on a program to
determine what functions are reachable from the realtime threads, I
don't know how to find the minimum set of memory addresses that
contain those function. Does anyone know if this can be done without
the debugging symbols?

--
Will Dyson
Received on Mon Feb 13 04:15:08 2006

This archive was generated by hypermail 2.1.8 : Mon Feb 13 2006 - 04:15:09 EET