Quoting Ismael Valladolid Torres :
I think what Lee is saying is that with realtime-lsm (and ingo's
spin-locking?), jackd, your audio apps, and limits.conf all set up
right all processes bow to your audio apps. So audio will still get the
lowest latency possible independant of other threads running on your
machine, including the window manager. The screen may not refresh as
frequently or be as responsive, but you should incur no addidional
XRUNS from using one window manager over another.
Am I right?
Its kind of a techincality though, because if your not getting any
XRUNS at a low latency, yet WM and thusly your interaction with your
machine isin't very responsive, then what is the advantage of no XRUNS?
So there needs to be a balance, and that is where WM's with a small
footprint fit in I guess. Because if it takes less resources to draw
the screen, screen redraws are more likely to be called from the
scheduler between audio app calls.
Please correct me if I am wrong, but that is my understanding.