Opened 4 years ago

Closed 4 years ago

#12498 closed defect (fixed)

[CL4] Scratch can not record audio normally, and show “Block cannot return”.

Reported by: tomyin Owned by: dsd
Priority: high Milestone: 13.2.0
Component: not assigned Version: not specified
Keywords: Cc: saadia
Blocked By: Blocking:
Deployments affected: Action Needed: add to build
Verified: no


OS: 31026o4
OFW: Q7B12
EC: 0.3.10

  1. Open the Scratch.
  2. Choose the sounds option, and click the Record.

Attachments (2)

scratch.jpg (982.6 KB) - added by tomyin 4 years ago.
block cannot return
ratetest.patch (4.9 KB) - added by saadia 4 years ago.
Show what is happening with Scratch record at rate 22050

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by tomyin

block cannot return

comment:1 Changed 4 years ago by dsd

  • Owner set to dsd

comment:2 Changed 4 years ago by dsd

  • Cc dsd added
  • Milestone changed from Not Triaged to 13.1.0
  • Owner changed from dsd to saadia

comment:3 Changed 4 years ago by saadia

  • Status changed from new to assigned

This occurs because the call to snd_pcm_hw_refine at line 401 of sound/core/pcm_native.c returns EINVAL (-22).
After turning on some of the RULES_DEBUG manifest in this file, I found that the RATE params snd interval is being reduced to an empty interval...

I added information to snd_interal_refine to show what's happening. Compare this with running 'arecord -f dat -r 22050 tmp.dat' which records at 22050. Try the attached patch to get this debug info.

Changed 4 years ago by saadia

Show what is happening with Scratch record at rate 22050

comment:4 Changed 4 years ago by dsd

  • Priority changed from normal to high

comment:5 Changed 4 years ago by dsd

  • Cc saadia added; dsd removed
  • Owner changed from saadia to dsd
  • Status changed from assigned to new

As of build 32 (with #12289 workaround: only support 48k sample rate for recording), if you open Scratch you can record a sound. We seem to have (temporarily?) hidden the "rate reduced to zero" problem described above.

But if you try to record another, or play a sound first, you can't record again. The error comes up.

The fundamental issue here is under these conditions, that Scratch tries to do playback (of silence) plus recording at the same time.

Our hardware can only support simultaneous record/playback if both streams run at the same rate. This is because SSPA_AUD_CTRL0 encodes "the rate" (via clock division) and this rate applies to both playback and capture. Our driver does not currently enforce this restriction; it probably should (via ASoC "symmetric_rates" mechanism), but we probably want to fix #12289 first. Scratch is trying to play back at 22050 and record at 48000 (since thats the only rate we made available).

If we restrict both playback and record to 48k, Scratch works OK. But thats probably not the solution we want.

comment:6 Changed 4 years ago by dsd

WIth the latest 13.2.0 setup with dmix enabled, the playback now happens at rate 44100 (as configured by dmix?) but it tries to record at 48000 at the same time.

The now-applied symmetric_rates mechanism tries to force a 44100 rate on the recording stream, but snd_pcm_hw_constraints_complete() then fails with -EINVAL because it seems to be requesting a rate of exactly 48k.

comment:7 Changed 4 years ago by dsd

  • Action Needed changed from never set to add to build
  • Milestone changed from 13.1.0 to 13.2.0

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.

comment:8 Changed 4 years ago by tomyin

"if you try to record another, or play a sound first, you can't record again. The error comes up."------Reproduced in 13.1.0 build 36 + OFW Q7B28

comment:9 Changed 4 years ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

Scratch sound recording is working in 13.2.0 build 4.

Note: See TracTickets for help on using tickets.