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. > > _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
