#12289 HIGH 4-softw: XO-4 audio recording sometimes only records silence (was: Audio recording on XO-4 in Linux isn't working)

[Zarro Boogs per Child]

#12289: XO-4 audio recording sometimes only records silence
---------------------------------+------------------------------------------
           Reporter:  cjb        |       Owner:  saadia       
               Type:  defect     |      Status:  new          
           Priority:  high       |   Milestone:  4-software   
          Component:  kernel     |     Version:  not specified
         Resolution:             |    Keywords:  audio        
        Next_action:  never set  |    Verified:  0            
Deployment_affected:             |   Blockedby:               
           Blocking:             |  
---------------------------------+------------------------------------------

Comment(by dsd):

 The factor at play here is the sample rate.

 Record requests 16k, which seems to only work rarely. 32k seems to work
 most of the time, but is not 100% reliable. 48k seems to be reliable all
 the time.

 You can test rates with:

 {{{
 #!/bin/bash
 for i in $(seq 0 100); do
         arecord -f dat -d 1 -r 32000 file.wav &>/dev/null || break
         out=$(sndfile-info file.wav | grep "Signal Max")
         set $out
         echo $4
 done
 }}}

 This exploits the fact that when recording works, we always record a pop -
 a bug we should fix someday. If '0' is reported in the output, this means
 that only silence was recorded, i.e. this bug was hit.

 When changing rates you should make sure that they were actually accepted
 by the hardware and codec (rather than being converted to something else
 in software), you can check what is actually being used by the hardware by
 looking at hw_params in debugfs.

 That script shows that 48k is reliable; 16k and 32k are not. Saadia has
 identified that this bug is sensitive to timing, e.g. adding printk or
 sleeps to the end of rt5631_hifi_pcm_params() makes 16k recording become
 noticably more reliable than before.

 To diagnose further, I would next suspect the DMA code. I wonder if we can
 check (using CPU access to memory) the audio SRAM data before the DMA
 engine copies it to main memory, and then check (again with the CPU) the
 main memory after the DMA is complete, verifying that the data was
 actually copied ok.

 Anyway, for now we are working around the issue by disabling all recording
 rates except 48k, in arm-3.5 1c6758a8be7b. If some software (e.g. Record)
 tries to record at a different rate, an automatic software resampling is
 performed.

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