On Tue, Dec 30, 2008 at 09:32:38AM -0500, Greg Smith wrote:
> That's great debugging and repair info. I especially like the use of the 
> stack trace command! That's a great trick for hunting down which process 
> is calling what files.

Actually, it's a system call tracing command.  It can be used to show
what a process is asking the kernel to do.  Yes, it is an essential
technical support tool.  It can also be used on processes that are
already running.

> Do we know how this gets in a failed state to begin with?

No, not yet.

I've two theories as to cause.  Seeing the content of a failed
/etc/asound.state file beside a working file from the same build would
help confirm the theories.  I hope these can be made available.  My
theories are:

1.  one of the mixer controls was changed by an activity or other
program, and not changed back, (this is the most likely),

2.  some hitherto undetected defect in "alsactl" or the way it is being
called by our OS build.

The mixer is the hardware component that controls the many output
volumes, the microphone sensitivity, and the use of the microphone input
jack as a voltage sensor.  The set of controls is referred to as the
mixer settings.  There are more controls in the set than are exposed to
the Sugar or activity user.  All the controls can be changed on the
shell command line.  The Sugar volume keys manipulate the main output
volume.  The Frame shows the current main output volume.  The Measure
activity manipulates the microphone and voltage sensor.  The mixer
settings are preserved over shutdown and reboot by the operating system.

/etc/init.d/halt is where the mixer settings are saved.

/etc/init.d/olpc-configure is where the mixer settings are restored.

(I wonder why we want to save and restore mixer settings anyway?  Would
it not be better to set them to default on each boot?)

I have excluded empty mixer settings file as a cause.  If the file is
empty, alsactl uses default settings, and these are not significantly
different to the working settings.  Tested on Joyride 2612.

Revision to my previous instructions ... merely moving /etc/asound.state
to another name and rebooting may solve the immediate problem though not
the cause.

James Cameron    mailto:qu...@us.netrek.org     http://quozl.netrek.org/
Devel mailing list

Reply via email to