On 2/12/06, Ismael Valladolid Torres <ivalladt@xxxxxxxxxxx> 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
