[PlanetCCRMA] Failure starting ALSA with an MAudio Delta 66

Tracey Hytry shakti@bayarea.net
Sat Apr 2 03:32:01 2005


Thursday night I spent a lot of time looking into this, mostly out of curiousity.  Well, you know what they say about curiousity and cats;  this one tried to kill off any sleep schedual I had.

I have an Audiophile 24/96 in this machine and was able to produce every error that people mentioned here.  This was all done in FC3 with the 2.6.11-0.3.rdt.rhfc3.ccrma kernel.

Most of the time I played with /etc/rc.d/init.d/alsasound, but I even managed to get the error while doing alsactl restore from the command line a few times.  I deleted and made new asound.state files a few times in there too.  It was a lot of fun modifying the alsasound script, and even going all the way back into checking out the rc and rc.sysinit scripts(it's been a long time and it was interesting to see what has changed, though I was too afraid to modify those two).

I wish I could say that I figured anything out?  I did discover a few things though, like the alsasound script may not be correct for fc3?  First off, alsascrdir=/etc/alsa.d on line 78 points to nothing(it's /etc/alsa on fc3).  From looking at the script it's obvious that the problem's coming when the script hits line 158, though not very obvious as to why it won't work with this script.  At first I thought that maybe something had changed in the redhat functions library that's used, but I was able to get the error by having the script do a "alsactl restore" in the problem area.

I tried all sorts of things besides modifying the alsasound script, such as linking /etc/alsa/ to alsa.d just so it might be happy.  I played with the asound.state a bit. but that file makes my head spin.  And I kept trying all sorts of things, many changes, many tests, and many reboots.

What I did seem to find is that the asound.state file is the most criticle part of this mess, so generating a good one goes a long way toward fixing the problem.  I don't mean making the file up myself, just asking the machine to generate it at the right time after setting up envy24control correctly.  I managed to get the machine so messed up one time that even hosing asound.state wouldn't let me shut down the alsa system or unload the drivers;  kind of pointing at something else much deeper then where I was playing(hello kernel/alsa).

I wasn't too upset that I could screw things up too badly, because I was just playing with the sound system after all.  I really wished I could have stayed up and worked on that into the following morning because it was fun studying how the whole kernel/modprope thing works(I only scratched the surface).

When I would really take alsa for a ride the wrong way down a one way street, I always knew that fc3 would be able to fix things for me if I:

Editted modprobe.conf and tossed any lines to do with alsa

erased(or renamed) asound.state

went into /etc/sysconfig/hwconf and deleted the lines about the sound card

     then

reboot and let kudzu re-find the sound card and rebuild the alsa stuff

go back to the mixer and set up the controls

then go do an alsactl store

       and

everything was back where I started. waiting for me to mess it up again :(


So, in the end I learned very little, except to watch out for that asound.state file and reboot often because my reality was centered in user space while most of the problem seems to float within the plane that the kernel lives in.  I never did find out why alsactl can be run from a command line and not from within the alsasound script;  but I guess that's for the gods to figure out, not this mere mortal.

But it was fun!

Tracey.