So, I enabled "loopback mode" in alsamixer, set xmms (with ALSA output) to play, and tried to record both video and audio (my previous motherboard had no loopback switch for its integrated audio, so specialized .asoundrc file setting up alsa loopback module was used). When I left recording settings to their default value of input frequency = 48000 I get strange one-core cpu overload in kernel space (orange color in gkrellm). I set input frequency to 44100 and everything was working smoothly from there. I also tried to record 1440*900*24bit*30fps with cpu set to its lowest frequency of 1.4Ghz. This usually resulted in video being shorter than audio, so I slowed video down to 0.68 or so via speed curve, and clipped few last silent frames. When CPU set to performance and can revv up to 4Ghz audio and video tend to be much more aligned as long as their lenght is concerned. codec was mjpeg444 / s16le into mov container on tmpfs. So I guess especially for screencapture on slow CPU running short pre-session capture will be useful to see if you can get same length tracks with given resolution/fps/codec and if no either drop down recording fps or try to speed up encoder settings. I tried other positioning methods (apart from software timings), check/uncheck add/drop frames checkboxes, setting different number of audio samples ... There seems to be no algo/code to intellectually duplicate frames that are too late in their encoding. I also tried setting buffered frames in device to absurdly high value like 50, and this was also not working for screencapture driver and recordings like 20-25 seconds long. It makes sense that no amount of buffering will save you if you are chronically late ... Sounds like trivial bits of info, but because I use cingg as my main screencapture application I thought I better to pen them down before I forgot!