#12400 NORM 13.2.0: Determine MMP3 audio buffer parameters

[Zarro Boogs per Child]

#12400: Determine MMP3 audio buffer parameters
------------------------------------+---------------------------------------
           Reporter:  dsd           |       Owner:  dsd          
               Type:  defect        |      Status:  new          
           Priority:  normal        |   Milestone:  13.2.0       
          Component:  kernel        |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  add to build  |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------
Changes (by dsd):

  * next_action:  test in build => add to build
  * component:  ofw - open firmware => kernel
  * blocking:  12343 =>


Comment:

 Thanks James. Unfortunately this half-broke audio recording, sorry for not
 testing that before. When recording at 48khz there is a loud audible pop
 every 171ms.

 Experimenting a bit, I found that audio recording is only clean when the
 first DMA transfer happens to a SRAM address on an 8kb boundary. And we
 now start the audio recording buffer at an offset of 62kb into the ASRAM,
 which clearly does not meet such constraints. And unfortunately, genpool
 (the layer that manages ASRAM allocations) does not allow us to request
 specific alignments.

 To work around that limitation, we can just round the allocation down to
 be cleanly divisible by 8192. Then when we make these allocations, genpool
 will make them contiguously at the start of ASRAM, and the allocations
 will be on 8kb boundaries as a result. This workaround is implemented in
 arm-3.5 a2200ace4. The 62kb suggested buffer size is now trimmed down to
 56kb.

 The firmware is still correct in suggesting 62kb buffer sizes - hopefully
 we will find a clean way to use all that buffer space some day.

 I also reverted an earlier hack (62abd4440) now that we have this fixed in
 the firmware, and also Squeak has been fixed to not request buffer sizes
 that are outside of what the hardware can offer.

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