I've done a little more experimenting. It does not reliably alternate between the working and non-working states with module reloads, that was a fluke. It seems to be random, and sadly it also seem to favor the non-working state. I've compare the contents of /proc/asound in both states, and nothing differs there - in particular, codec#0 has exactly the same contents, whether the module load was "good" and gives me sound, or is "bad" and renders my computer silent. For now, i just restart the alsasound init script until my sound works.
The only difference I can find is that when my sound does *not* work, the mixer has a simple mixer control labeled "SPDIF". My laptop lacks a physical SPDIF port, but perhaps when this happens, sound is being directed to an (unconnected) SPDIF output on the codec? In the "good" state, there is only the "Master" mixer control, and it can adjust the volume and mute/unmute my sound. The sound is also automatically redirected to the headphones if they are plugged in. Another oddity: in the "bad" state, alsamixer shows a "Master" and a "SPDIF" volume control. I can adjust and mute/unmute them independently, but if i close and reopen alsamixer, they will both match the state of whichever I adjusted last. -- Andrew Mahone andrew DOT mahone AT gmail DOT com ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
