Re: #12498 HIGH 13.2.0: [CL4] Scratch can not record audio normally, and show “Block cannot return”.

[Zarro Boogs per Child]

#12498: [CL4] Scratch can not record audio normally, and show “Block cannot
return”.
------------------------------------+---------------------------------------
           Reporter:  tomyin        |       Owner:  dsd          
               Type:  defect        |      Status:  new          
           Priority:  high          |   Milestone:  13.2.0       
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  add to build  |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------
Changes (by dsd):

  * next_action:  never set => add to build
  * milestone:  13.1.0 => 13.2.0


Comment:

 Scratch actually requests playback at rate 22050, but we now go through
 dmix which is configured (by us) to default to 44100. Then that stream is
 left running.

 When we now come to start recording, snd_pcm_open() is actually what fails
 - long before we've even had a chance to select a rate. But with symmetric
 rates now required it is obvious why - the system notices that another
 stream is active with rate 44100, and restricts the recording stream to
 rate 44100. However the only recording rate available is 48000 at the
 moment (due to #12289) so the system realises that it cannot satisfy its
 requirements and refuses to create the stream.

 To fix this, we should recognise that we're trying to offer the
 simultaneous playback and capture but are also restricted by the symmetric
 rates requirement. Therefore we should not offer any playback rates that
 we cannot capture at, and vice versa, to prevent any possibility of
 entering the above situation. This is fixed in arm-3.5 2c19b318 where we
 now only offer a single rate for playback/capture: 48000.

 With this in place, it seems silly for us to be configuring dmix to use
 44100 (instead of its 48000 default). That configuration change was only
 intended to work around an XO-1.5 bug anyway, so I have moved it to being
 XO-1.5-specific in olpc-os-builder d55ae1193b.

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