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!
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 will try to add this to the manual in the Editing: real-world usage cases section for others to learn from your experience.
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.
Andrew, adding this to Manual Real-World in Appendix D. Did I miss
anything or say something wrong? Using Screen Capture on slower CPUs Some results with different settings when working on slower CPUs follow: - 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. - 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. - 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. - 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. - 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. - 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.
ср, 20 дек. 2023 г., 02:29 Phyllis Smith <[email protected]>:
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.
Andrew, adding this to Manual Real-World in Appendix D. Did I miss anything or say something wrong?
May be add still working link to .asoundrc I googled 6 years ago? https://bbs.archlinux.org/viewtopic.php?id=147852 I added few more words in {} I wonder if this cpu-eating effect affect just my combo of kernel and hardware, or more widespread ...? I'll try my laptop too.
Using Screen Capture on slower CPUs
Some results with different settings when working on slower CPUs follow:
- You can enable "loopback mode" in alsamixer, set xmms (with ALSA output) to play {any alsa-enabled app should work}, 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. - 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 likely will want to set the input frequency to 44100 and then everything should work smoothly. - Attempting to record 1440*900*24bit*30fps with cpu { AMD FX 4300 } 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. - 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. - 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. - 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.
May be add still working link to .asoundrc I googled 6 years ago?
OK, will work on reading that and picking out the relevant part (probably tomorrow though).
I added few more words in {}
OK, will add.
I wonder if this cpu-eating effect affect just my combo of kernel and hardware, or more widespread ...? I'll try my laptop too.
I have a sloooooooow laptop I can try to test when I have time and if I remember!
participants (2)
-
Andrew Randrianasulu -
Phyllis Smith