#12400 NORM 13.1.0: XO-4 etoys audio is bad

[Zarro Boogs per Child]

#12400: XO-4 etoys audio is bad
--------------------------------------+-------------------------------------
           Reporter:  dsd             |       Owner:  saadia       
               Type:  defect          |      Status:  new          
           Priority:  normal          |   Milestone:  13.1.0       
          Component:  etoys-activity  |     Version:  not specified
         Resolution:                  |    Keywords:               
        Next_action:  diagnose        |    Verified:  0            
Deployment_affected:                  |   Blockedby:               
           Blocking:                  |  
--------------------------------------+-------------------------------------
Changes (by dsd):

 * cc: wmb at laptop.org (added)


Comment:

 The above debug messages came out in jumbled order, so that wasn't
 anything interesting.

 Reverted commit 858059d215b8d386eaf320bd17355cb185c3eab7 in arm-3.5 to
 take us closer here.

 What is happening here is that Squeak requests that the hardware buffers
 the first 7/8 of the sound before automatically moving from PREPARE to
 START state (and hence playing the sound). In the case of the meow, this
 is 2313 frames.

 However, on XO-4, there are only 1024 frames available in the hardware
 buffer. Thats why the third writei doesn't manage to copy any more data
 in, and the playback never starts, so it just sits there looping around
 with a full buffer.

 atest3.c demonstrates this. XO-4 has 1024 frames available here, but
 XO-1.75 had 3968.

 This is definitely bad behaviour from squeak here, it is asking for a lot
 of buffering and introduces perhaps more latency than necessary before it
 starts playing the sound. At the same time I imagine a good XO-4 audio
 experience also needs a good hardware buffer size to be available so it
 would be nice to "fix" this on the kernel side anyway.

 The low number on XO-4 originates from the default values hardcoded in
 mmp_pcm_probe(). We don't get these from DT, looks like that info is not
 there in current firmware releases. If I increase this to match
 arm-3.0-wip/XO-1.75, i.e.:
 {{{
         pbbuf = 15872;
         pbper = 4096;
 }}}

 then I now get 3072 available. Not as many as XO-1.75, but reasonable, and
 enough to satisfy squeak.

 Saadia and I don't have a complete understanding of these values and their
 constraints. So, questions for Mitch would be:
  1. Why are the values in mmp_pcm_probe() so low? Should these be  coming
 from DT?
  2. What are good values for XO-4? Is the SRAM size the limit here? What's
 the size of the MMP3 audio SRAM?

 I will also work on improving Squeak's buffering behaviour, but preferably
 for inclusion in a future release rather than this one.

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