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!
