#10168 BLOC 1.5-sof: Scratch can freeze up after playing sound
Zarro Boogs per Child
bugtracker at laptop.org
Tue Jun 1 14:21:13 EDT 2010
#10168: Scratch can freeze up after playing sound
--------------------------------+-------------------------------------------
Reporter: cjb | Owner: cjb
Type: defect | Status: new
Priority: blocker | Milestone: 1.5-software-update
Component: kernel | Version: not specified
Resolution: | Keywords:
Next_action: diagnose | Verified: 0
Deployment_affected: | Blockedby: 6201
Blocking: |
--------------------------------+-------------------------------------------
Comment(by pgf):
current thoughts, extracted from an email message. sorry about the
duplication for some folks.
{{{
i'm looking at sqUnixSoundALSA.c from:
http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/unix/vm-sound-
ALSA/sqUnixSoundALSA.c?rev=2168&view=auto
it's not clear to me that ignoring ESTRPIPE (if that's what was
tried) is the right answer. it seems that alsa's (ab)use of
ESTRPIPE is an indication that the sound system was suspended,
and that (for some reason) one needs to explicitly tell it to
resume, or, failing that, to re-"prepare" it. search for
"ESTRPIPE" on this page:
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html
and if you find that description a bit opaque, try clicking
through to the snd_pcm_resume() doc, which makes it a bit more
clear.
i don't know enough about how alsa really works to understand
whether this is an alsa problem -- i haven't tried to determine
whether alsa should be doing the resume itself (as it seems it
should do).
(if "suspend" and "resume" mean something different in the sound
world than they do to the rest of the kernel, then a) that's
unfortunate, and/or b) perhaps the problem is that kernel suspend
shouldn't be putting alsa into state SNDRV_PCM_STATE_SUSPENDED.)
}}}
--
Ticket URL: <http://dev.laptop.org/ticket/10168#comment:10>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list