#12289 HIGH 4-softw: XO-4 frequently records silence at non-48k rates (was: XO-4 audio recording sometimes only records silence)

[Zarro Boogs per Child]

#12289: XO-4 frequently records silence at non-48k rates
---------------------------------+------------------------------------------
           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):

 I think we have strong reason to believe that the DMA code (audio FIFO to
 SRAM) is bug-free. This is because the DMA parameters for a recording at
 48k sample rate are '''identical''' to a recording at a 32k sample rate.
 Yet 48k is 100% reliable, and 32k (and other rates) is clearly unreliable.
 This code is in drivers/dma/mmp_tdma.c.

 One programatic way to determine whether a recording was silent or not is
 shown above. For a lower level technique, mmp_tdma_chan_handler() can be
 modified to print out the first 4 bytes of data transferred in each DMA
 period. When a silent recording happens, the data is zero. When the
 recording is good, non-zero data is readily seen. This confirms that in
 the failure case, the recorded data is being lost at the earliest point
 possible in the driver architecture - this DMA is the first door that the
 recorded data passes through on its way to being processed/stored.

 Printing out the first 4 bytes of each period is enough to eliminate the
 possibility that audio is arriving on the wrong channel, since 4 bytes
 covers both channels.

 Checking the DMA destination address register seems sane. It auto-
 increments by 2048 bytes every time a DMA interrupt arrives.

 I have also moved over our more extensive resetting code from our 3.0
 kernel for MMP2. This does not have any obvious effect on the
 success/failure rate. The resultant patch is
 http://dev.laptop.org/~dsd/20130227/tdma-reset.patch

 Testing recording at 32k. Here recording sometimes works, sometimes fails,
 maybe 50% probability each way. There is no difference in the codec
 registers between the success and failure case. Here is the register dump:

 {{{
 reg 00: 0
 reg 02: 4040
 reg 04: 4040
 reg 06: a080
 reg 08: 0
 reg 0a: 808
 reg 0c: 0
 reg 0e: 0
 reg 10: 101
 reg 12: 0
 reg 14: b0b0
 reg 16: 0
 reg 18: 10
 reg 1a: dfc0
 reg 1c: dfc0
 reg 1e: 88c0
 reg 20: 88c0
 reg 22: 5588
 reg 24: 3000
 reg 26: 8808
 reg 28: e8e8
 reg 2a: 6c00
 reg 2c: 0
 reg 2e: 0
 reg 30: 0
 reg 32: 0
 reg 34: 8000
 reg 36: 8000
 reg 38: 1010
 reg 3a: 8c80
 reg 3c: e000
 reg 3e: 0
 reg 40: 7e00
 reg 42: 0
 reg 44: 0
 reg 46: 0
 reg 48: 0
 reg 4a: 4f1c
 reg 4c: 0
 reg 4e: 0
 reg 50: 0
 reg 52: 2040
 reg 54: 0
 reg 56: 8000
 reg 58: 0
 reg 5a: 0
 reg 5c: 7e0
 reg 5e: 0
 reg 60: 0
 reg 62: 0
 reg 64: 206
 reg 66: 2000
 reg 68: 553
 reg 6a: 48
 reg 6c: f73c
 reg 6e: 0
 reg 70: 0
 reg 72: 0
 reg 74: 0
 reg 76: 0
 reg 78: 0
 reg 7a: 3
 reg 7c: 10ec
 reg 7e: 6132
 }}}

 The SSPA registers also do not show a change between success and failure
 cases. The RXID register does sometimes change between 0 and 1 on
 different runs, but it also does that for two successive success cases, so
 cannot be a cause of failure.

 {{{
 RXD         00000000 RXID        00000000
 RXCTL       000801a5 RXSP        01f503f1
 RXFIFO_UL   00000000 RXINT_MASK  00010000
 RXC         da120100 RXFIFO_NOFS 00000000
 RXFIFO_SIZE 00000047
 CTRL0 00000d03
 CTRL1 a00da191
 CTRL2 30010801
 TXD         00000047 TXID        00000000
 TXCTL       00080000 TXSP        00010000
 TXFIFO_LL   00000000 TXINT_MASK  00000000
 TXC         da130100 TXFIFO_NOFS 00000000
 TXFIFO_SIZE 00000047
 }}}

 I think the next diagnosis step is to hook up a scope to the LRCK, BLCK
 and ADCDAT lines of the codec, while recording at 32k. Analyzing these
 signals will be able to tell us if the codec is producing all-zero data in
 the failure case, and tell us if the problem is within the codec or within
 the SoC. See section 7.4.1 of "ALC5631Q DataSheet_0.91.pdf".

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