[LAU] lost sound (it had been working)

[Reid Vail]

I will try these things, absolutely. 

Can I capture the /var/lib/alsa/asound.state file on a booted liveCD (to 
a jump drive, for example) and then just save it in my production system?

Also, I was thinking it could be a conflict of some kind.   Not sure 
exactly where the competition would be;  just thinking.

Thanks

Reid

James Cameron wrote:
> On Tue, Jan 20, 2009 at 07:48:01PM -0500, Reid Vail wrote:
>   
>> I loaded Knopix 5 .1 and the sound worked perfectly right away...and  
>> that's not a very old version ( < 2 years I think).  So then I loaded  
>> the Ubuntu 8.10 liveCD and it also worked fine.
>>     
>
> Interesting, and useful data.
>
>   
>> So this is not a speaker problem or a hardware (MB "soundcard" problem)  
>> and it's not an old software vs. new software problem.  It can only be a  
>> configuration problem.
>>     
>
> Yes, that seems likely, unless your software is different to the Ubuntu
> 8.10 liveCD kernel, such as may happen if you have applied updates.
>
>   
>> Thinking of trouble-shooting scenario, I wonder if it makes sense to   
>> reload the liveCD, capture the config and then boot off the HD and  
>> compare what's in place to what worked on the liveCD?  If you think  
>> that's worthwhile can you let me know which configuration settings to  
>> capture.
>>     
>
> Okay.  We've been having this problem on the OLPC XO lately, so I'm up
> on it.  All the ALSA controls are stored on shutdown and restored on
> boot, for most distributions of Linux.  The command
>
> "alsactl store" saves the controls, and the command
>
> "alsactl restore" restores them.
>
> There's a --file option for telling it where to store into or restore
> from.  The default location is distribution specific.  Fedora in one
> place, Debian in another.  Ubuntu is derived from Debian.  It is easy to
> find, just run the command
>
> 	strace -e open alsactl store
>
> On an Ubuntu 8.10 test system here, the file is
> /var/lib/alsa/asound.state
>
> The file is text, in my experience, and can be compared with previous
> files.  The file content is sound card and driver version specific, but
> driver authors tend to accept the old file in new versions of driver.
> (Gross simplification).
>
> So on the assumption that your problem is ALSA controls, do a store in
> each of the operating system environments you have tried, and compare
> the output mechanically, e.g. with the diff command.  There are some
> handy graphical diff programs around, I use kdiff3 or emacs.  Capture
> all the files first before making any change, so that you can tell why
> it is happening.
>
> If you see a difference, try to understand it.  Try to restore that file
> on the non-working environment.  It may fix the problem.
>
> If you see a difference in that there are more or less controls, then
> the cause will be change in the driver between the different
> environments.
>
> If you see no difference at all, then the cause of your problem won't be
> ALSA controls, and you should look at drivers.
>
> There yet may be other causes.
>
>