Zod, as I said in my previous post...
As for auto-frameskip, the only real way to get it running reliably in my experience (which is quite extensive in emulation under windows, but not linux), is to use two threads and a series of sound buffers for synchronisation.
The main thread, running at normal priority, will emulate the CPU etc - and will, at the end of each frame's worth of opcodes, enter an "idle loop" while it waits for the sound buffers' play position to reach the start of a new buffer (with each buffer being one frame's worth of sound samples). at the start of that idle loop, it signals a lower priority thread to begin building the frame graphics. Because the main, higher priority, thread has entered an idle loop, the graphic thread gets CPU time.
If the graphic thread finishes building graphics before the idle loop finishes, then all is well and you get the full 50 or 60fps. If not, then the CPU thread takes over again and the graphics thread won't get to finish building graphics until the next idle loop. This way, frames will skip if there's not enough CPU time to complete them.
because you're waiting for sound synch, you get perfect sound (unless the emulator cannot cope in the CPU thread, when there's no way you're going to get any sort of smooth emulation), and a proper, correct auto-frameskip.
As I say, I've been doing this under windows for a few years now and it works very well indeed. I've messed with various methods of checking and computation to see if frames need to be skipped, and none have been as reliable as this. I don't know if you can implement this without a significant rewrite, or even if you can do this at all under linux on the 2x, but it may be worth a shot.
hope it helps, feel free to ignore it though
D.
