#9949 NORM 1.5-sof: Recording no smoothly while do record test in sugar

[Zarro Boogs per Child]

#9949: Recording no smoothly while do record test in sugar
---------------------------------------+------------------------------------
           Reporter:  Andy Pei         |       Owner:  dsd                               
               Type:  defect           |      Status:  new                               
           Priority:  normal           |   Milestone:  1.5-software-later                
          Component:  record-activity  |     Version:  1.5 Software Build os64 aka 10.1.0
         Resolution:                   |    Keywords:                                    
        Next_action:  reproduce        |    Verified:  0                                 
Deployment_affected:                   |   Blockedby:                                    
           Blocking:                   |  
---------------------------------------+------------------------------------

Comment(by Quozl):

 Occasional drops are caused by failure to keep reading the ALSA device at
 the rate implied by the sample rate and the other device parameters.

 arecord is an alternate ALSA reading implementation that can be used as
 comparison.  Record uses gstreamer.

 arecord at 11025 samples per second consumes 0.6% of CPU on an XO-1.5.

 Discarding output always works fine:
 {{{
 arecord --rate 11025 --file-type /dev/null
 }}}

 Therefore there is no underlying problem with the sound hardware,
 interrupts, or the ability of the CPU, kernel, ALSA and arecord to keep up
 with the data flow.

 Writing output to external USB stick never causes overruns.

 Writing output to internal SD always causes overruns:
 {{{
 arecord --rate 11025 --file-type raw test.raw
 overrun!!! (at least ${SILLY_NUMBER} ms long)
 overrun!!! (at least ${SILLY_NUMBER} ms long)
 }}}

 Watching the scheduler counters for the arecord process is instructive:
 {{{
 watch -d --interval=0.1 cat /proc/$(pgrep arecord)/sched
 }}}

 se.avg_wakeup is normally five per second for USB or /dev/null output, or
 4.999993 for SD output.

 When using SD output, every now and then it jumps downward, showing that
 the process has not kept up with the necessary I/O ... when this happens,
 there are flashes of blocking and waiting.  They correspond in time to
 internal SD write events:
 {{{
 watch -d --interval=0.1 grep mmc /proc/diskstats
 }}}

 Writing to internal SD from another process (using scp to copy a file from
 another system) while arecord is writing to USB, does not cause any
 overruns, and does not cause any changes to the sr.avg_wakeup rate of the
 arecord process.  There are plenty of expected nr_involuntary_switches.

 Therefore, the reason for the overruns is the occasional blocking of the
 writes to the SD filesystem made by arecord.  These writes must be
 blocking for longer than 200ms.

 Now, the overruns can be prevented in this test by piping the arecord
 output to a cat process which then writes to SD:

 {{{
 arecord --rate 11025 --file-type raw - | cat > test.raw
 }}}

 So I think the process that reads from the ALSA device in the Record
 software stack needs to be given every opportunity to keep reading and not
 stalling.

-- 
Ticket URL: <http://dev.laptop.org/ticket/9949#comment:8>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system