RE: [gentoo-user] [Completely and totally OT] FVWM-Crystal...!!!

["Dave Nebinger" <dnebinger@joat.com>]

> Were I you, I would consider:
> 
>  - If keeping X, switching to the absolute most minimal wm possible
> (twm, ratpoison, ion), to see what effect that had.
>  - If downstepping from X, investigating what programs run under
> DirectFB  and seeing what effect that had.
>  - If going cold-turkey off X, seeing how far you get with the
> command-line and ncurses programs.

I would also add the following: remoting X.  X is a hog, as Holly said, but
there's no reason the X server would need to run on the same box as the
ongoing recording session.

Running two systems, one running X and handling the gui operations, and one
running your audio apps, might provide enough of the separation to reduce
the latency on the audio box.  Of course the two cards should probably be
connected with at least a 100mb Ethernet connection (to eliminate the
overhead of dealing with the network conversations for X).

Another possibility might be your choice of filesystems (assuming the
recordings are going to disk).  Different filesystems have inherent latency
based upon their design - journaling adds overhead, btree maintenance in
reiser adds overhead, etc.  Just using a simple ext2 filesystem for the
initial recording followed by backups to a modern filesystem may have a
measurable impact.

Going back to X, it is a hog both in cpu cycles and in memory; you mention
having an amd64 but no quotes on memory.  My assumption is that such a
system has a big chunk of memory, but I've learned what happens when one
assumes.  Obviously a lack of sufficient memory can cause you some swapping
issues whether you were aware of it or not.


-- 
gentoo-user@gentoo.org mailing list