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

[Tiago Marques]

Hi,

I was just looking into this and the issue with SD cards' random write
performance intrigued me in this particular case.
Isn't recording being performed sequentially, hence no lag problem? At
least, it should be somewhat mitigated, filesystem might be causing
problems?

Anyhow, I have been looking into how to go around the random write problem
and NILFS2 popped up. In theory it seems a very capable way of having a
whole lot better performance, as it should only perform sequential
writes(unfortunately only partially). Anyone tried it before choosing ext3?

I have still not gotten to backuping the fs and moving it to NILFS2. It even
has SSD options and can suspend the garbage collector within some criteria,
helping alleviate the wear issue.

Best regards,
Tiago


On Thu, May 6, 2010 at 6:40 AM, Zarro Boogs per Child <bugtracker at laptop.org
> wrote:

> #10045: XO-1.5 Record audio/video are out of sync with each other
>
> ---------------------------------------+------------------------------------
>           Reporter:  wad              |       Owner:  dsd
>               Type:  defect           |      Status:  new
>           Priority:  high             |   Milestone:  1.5-software-update
>          Component:  record-activity  |     Version:  Development build as
> of this date
>         Resolution:                   |    Keywords:  camera record XO-1.5
>        Next_action:  diagnose         |    Verified:  0
> Deployment_affected:                   |   Blockedby:
>           Blocking:                   |
>
> ---------------------------------------+------------------------------------
>
> Comment(by Quozl):
>
>  A significant improvement in video recording is achieved by moving the
>  instance directory for the Record activity off the SD card.
>
>  The result was no significant pauses in video motion during recording, and
>  a much more predictable A/V latency.
>
>  The downside is restricted recording time.
>
>  This suggests that the current problems with recording are due to the SD
>  writes.  See #9688 (terrible SD write performance: wontfix), #9995
>  (optimise kernel write block size), and #10112 (GUI freezes on fsync).
>
>  While this is not the best way of doing it, this is the method I used:
>
>  * start Record,
>  * copy the directory to a large enough tmpfs,
>  {{{
>  cd .sugar/default
>  rsync -a org.laptop.RecordActivity /dev/shm
>  }}}
>  * remove the old directory and create a symlink,
>  {{{
>  rm -rf org.laptop.RecordActivity && \
>  ln -s /dev/shm/org.laptop.RecordActivity
>  }}}
>  * continue using the Record activity.
>
>  (This symlink persists until removed ... and since /dev/shm is empty next
>  boot the Record activity will fail to start.)
>
> --
> Ticket URL: <http://dev.laptop.org/ticket/10045#comment:25>
> One Laptop Per Child <http://laptop.org/>
> OLPC bug tracking system
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100508/b4f9bc1d/attachment.html>