#10045 HIGH 1.5-sof: XO-1.5 Record audio/video are out of sync with each other

[James Cameron]

On Wed, May 12, 2010 at 10:31:50AM -0400, Martin Langhoff wrote:
> On Wed, May 12, 2010 at 1:46 AM, James Cameron <quozl at laptop.org> wrote:
> > With the 250Mb test I've been doing, this causes 8 seconds in dd, 147
> > seconds in sync, and a nice distribution of write latencies (largest
> > samples 0.2s 0.1s 44ms 15ms 8ms, median 85us, smallest sample 80us).
> 
> Great! Must say that dirty_ratio=90 seems high -- default is 20, which
> is 20% of available memory.

It implies buffering as much as possible.  This is also evident in the
write syscall latency distribution.

> can you test with
> 
> vm.dirty_writeback_centisecs=100 # frequent pdflush process wakeups
> vm.dirty_expire_centisecs=500 # make data qualify for pdflush earlier
> vm.dirty_background_ratio=10 # pdflush should start working early
> vm.dirty_ratio=30 # or maybe 40 -- this is the backstop
> 
> this should kickoff a background writer early, and make data "ripe"
> for it to flush early too.

Tested.  I used dirty_ratio of 40%.  Changes the particular test to take
44 seconds in dd, 110 seconds in sync (an equivalent time differently
distributed), and write syscall latency largest samples are 11, 9, 8, 7,
and 0.44 seconds.

We discussed this briefly in team meeting this morning ... Record is
writing an uncompressed stream to SD, before then compressing it in the
"Save" step once the video recording is stopped.  (I could be wrong).

This means that no matter what the size of the buffer memory, if the
data rate from the camera exceeds the rate at which we can write to SD,
there will be skips once a recording is long enough to fill the buffer.

(The dirty_* parameters help us change how the kernel responds to these
writes, but we could equally well add a software buffer ... in the end
we use more RAM for no gain.)

So we determine the data rate by choosing height, width, and frame rate
from the camera.  We determine the maximum rate according to the choice
of SD media.

Working with uncompressed data is marginally preferrable to on the fly
compression ... using on the fly, the avoidance of delays would depend
on the compression ratio, which would depend on the complexity of the
changes from frame to frame.  Hand waving becomes expensive.

If we can get smooth recording at chosen video source rates, without
compression, to our SD media, then on the fly compression should work
fine.

-- 
James Cameron
http://quozl.linux.org.au/