On 9/29/05, Dave Nebinger <[EMAIL PROTECTED]> wrote: > > 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).
This is an interesting idea actually. I currently run two boxes anyway. All audio is connected between them using ADAT optical (i.e. - red laser) or spdif so I've got 26 digital audio channels going across. Maybe running remotely could solve some of this. Thanks. > > 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. In fact it does. I wrote a short online paper about that a few years ago. I use ext3. > > 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. Thisis a good point also. The machine has 512MB. This has been more than enough on my previous 32-bit machines, but on this AMD64 running the Gentoo 64-bit kernel it seems that memory usage is significantly higher. On the 32-bit machine I seem to use about 300-350MB by the time I have Gnome up and maybe Firefox open. I alomost have never seen swapping. On the AMD64 I'm seeing 450-500MB and a small amount of swapping every day. I'm unclear about the 64-bit environment anyway. OK, it's 64-bit, but I also have a pile of emulation libraries emerged to take care of dependencies. I don't know when they are getting used, except for the 32-bit Firefox I'm running so that I get more multimedia stuff. Anyway, more memory may well be a good thing to do. Thanks for the ideas. -- gentoo-user@gentoo.org mailing list
