Ticket #12677 (closed defect: fixed)

Opened 11 months ago

Last modified 11 months ago

Pygame causes ALSA underruns due to small period size on XO-4

Reported by: godiard Owned by: Quozl
Priority: normal Milestone: 13.2.0
Component: ofw - open firmware Version: 4-C1
Keywords: pygame Cc: dsd, dirakx, garycmartin
Action Needed: add to build Verified: no
Deployments affected: Blocked By:
Blocking:

Description

Physics and Maze use a lot of cpu (50% aprox) without doing anything. The log show a continue stream of:

ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred.

The activities don't use sound at all.

Just to compare, in xo-1 use 39% cpu, and don't show the error msg, and in xo-1.5 use 20% cpu.

Using the activity Maze on xo-4 for a while, I saw random crashes. (The easier way to trigger it was rotate the screen a few times, I am not sure if is related or not)

Attachments

Change History

  Changed 11 months ago by walter

  • keywords pygame added

This problem is likely an issue below the level of the recent changes made to the activity itself since it occurs on v11 of Physics as well.

  Changed 11 months ago by dsd

All of those CPU usage figures sound far too high.

pygame is initialising audio and playing silence even when the app does not request it. That is quite unfortunate...

  Changed 11 months ago by walter

FWIW, the problem goes away on an XO1.75 running Sugar 0.94.1.

  Changed 11 months ago by godiard

Just to be sure, I tested again with xo-4, os6, after update the kernel due to audio bug, but is similar. I agree pygame is playing silence and that should be solved. Anyway there are another problem, because we don't have problems on xo-1

  Changed 11 months ago by dsd

  • owner set to Quozl
  • summary changed from Pygame activities use a lot of cpu and show alsa error on XO-4 to Pygame causes ALSA underruns due to small period size on XO-4
  • component changed from not assigned to ofw - open firmware
  • milestone changed from Not Triaged to 13.2.0

I think the problem (high CPU usage) occurs on all platforms, but I guess you are viewing specifically the error spew as a cause for concern.

James, please increase the max period size provided by the firmware (in #12400) from 2048 to 4096, this matches XO-1.75. SDL works with a low number of periods so increasing the size of each period gives it more leeway to avoid underruns.

  Changed 11 months ago by Quozl

  • owner changed from Quozl to dsd

Fixed in svn 3657, with a brick-tested build at q7b30jb.rom. Let me know when you need a release.

follow-up: ↓ 9   Changed 11 months ago by godiard

Looks like pygame.mixer.init() is called by pygame.init()

http://www.pygame.org/docs/ref/mixer.html#pygame.mixer.init

Should be good try stop it.

  Changed 11 months ago by walter

Maybe we can get a patch upstream to make mixer.init() an option. Hate to have to carry around our own version.

in reply to: ↑ 7   Changed 11 months ago by godiard

Replying to godiard:

Looks like pygame.mixer.init() is called by pygame.init() http://www.pygame.org/docs/ref/mixer.html#pygame.mixer.init Should be good try stop it.

Reply to myself:

Adding:

pygame.mixer.quit()

after

pygame.init()

on olpcgames.canvas(), solves the cpu problem (go to 10% on maze standby and 2% on physics).

A pending issue is at the activity startup, a crispy sound is heard. I am testing if using preinit [1], can set a value to not hear the sound at all.

As olpcgames is death as a library, and development has moved to sugargames, may be is ok solve the cpu problem in the activities, and implement a better solution on sugargames. Sadly, these libraries are copy/pasted in the activities using them.

[1] http://www.pygame.org/docs/ref/mixer.html#pygame.mixer.pre_init

  Changed 11 months ago by godiard

No improvements using pre_init, any idea about what numbers should be sane or if have sense at all try to avoid the crispy sound at startup changing the parameters?

  Changed 11 months ago by walter

I too tried a number of pre-init configurations... no luck there. But I think Quozi has a patch to the audio driver params that fix the immediate problem.

  Changed 11 months ago by godiard

  • cc dirakx, garycmartin added

Sent patch to both maintainers (diraks, and garycmartin) and requested a new release before 13.2.0 (23th of May) if possible.

  Changed 11 months ago by dsd

If the sound device is being opened you won't avoid the audible pop. This is a codec driver bug though that will hopefully be solved one day (since the codec specs document a de-pop routine).

  Changed 11 months ago by Quozl

  • owner changed from dsd to Quozl
  • next_action changed from diagnose to package

  Changed 11 months ago by Quozl

  • next_action changed from package to add to build

Is in Q7B31.

  Changed 11 months ago by dsd

  • status changed from new to closed
  • resolution set to fixed

Tested 13.2.0 build 7 on XO-4, launching Maze does not produce log spam.

Note: See TracTickets for help on using tickets.