<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">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.</div><br></div></blockquote></div></div></blockquote><div> <span class="gmail_default" style="font-size:small">Andrew, adding this to Manual Real-World in Appendix D.  Did I miss anything or say something wrong?<br></span><h1>Using Screen Capture on slower CPUs
</h1>

<p>
Some results with different settings when working on slower CPUs follow:

</p><ul><li>You can enable "loopback mode" in alsamixer, set xmms (with ALSA output) to play, 
and then you can record both video and audio. If your motherboard has no loopback switch
for its integrated audio, you can use a specialized .asoundrc file set up as an alsa
loopback instead.
</li><li>If you leave recording settings to their default value of input frequency = 48000, you
may get strange one-core cpu overload in kernel space. This will show up in the color
orange if using the system monitor software, gkrellm (GNU Krell Monitors). So you most
likley will want to set the input frequency to 44100 and then everything should work
smoothly.
</li><li>Attempting to record 1440*900*24bit*30fps with cpu set to its lowest frequency of 1.4Ghz,
usually results in video being shorter than audio, so try slowing video down to different
values, such as 0.68 or so via speed curve, and then just clip the few last silent frames.
</li><li>If you set the CPU up for performance and if you can rev it up to 4Ghz, then audio and
video tend to be much more aligned in terms of their length.  In one particular case with
generally good results, the codec was mjpeg444 / s16le into a mov container on tmpfs.
</li><li>Specifically 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
not, either drop down recording fps or try to speed up encoder settings.
</li><li>In trying other positioning methods, apart from software timings, such as check/uncheck
add/drop frames checkboxes and setting different number of audio samples ... , there seems
to be no algorithm/code to intellectually duplicate frames that are too late in their
encoding. And setting buffered frames in the device to absurdly high value like 50, was 
also not working for screencapture driver and short recordings like 20-25 seconds long.
In conclusion, no amount of buffering will save you if you are chronically late.
</li></ul></div></div></div>