> 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
