Just added a small startup optimization (speculative start):
https://bitbucket.org/hudson/magic-lantern/commits/50209fff8bbbBefore, it was writing to the card as soon as there was one captured frame in the buffer. Even if this meant it was writing a little slower.
Now, it starts writing as soon as there is one frame captured, but the write command is issued in advance, for the entire contiguous memory area. Of course, subsequent frames will be captured while writing. As long as the file writing task is slower than frame capturing task, this trick will work.
(Don't confuse this with pre-buffering.)
Obviously, this technique is inherently unsafe. If, for some reason, the card controller starts writing 120% faster than we have measured, the risk is that we may save a frame that does not contain complete image data.
In theory, I can detect this situation, and I've added quite a few consistency checks. I did not encounter any lost frames yet.
Don't expect miracles from it. On my cards, I did not get any noticeable improvement, other than prettier buffer graphs (with large steps from the very beginning) and the mathematical proof that both startup and cruise "segments" are saved at the maximum speed possible with standard file I/O.
I expect it to work a little better on Ted's card, where yesterday's method didn't work very well.
And of course, since the optimization is a little unsafe, it's turned off by default.
Binary (same link):
raw_rec.mo
