As far as I know, this particular crystal sound chip is really very new to the kernel anyway, and (sadly) several sound drivers have problems after being put to sleep. The workaround is fairly evil - to unload the module before allowing sleep, so that it can be reloaded afterwards, which it may be unwilling to do, if there is something using sound at the time. Yet, if there *is* something using sound at the time you suspend, (if other cases are similar) you have a small but finite chance of getting a feedback-like squeeeeeeeeeeeeeal when it awakens, until you manage to kill -9 the offender.
All of this is no fun and it would be nice if the new stuff contains some sort of smarter soundcore which can deal with sleep/wake much more sanely. However Alan hasn't many laptops to work with and I suspect a lot of the rest of the core guys don't have any. So if you are one of the sufferers (I'm not - my sound chip is a well supported old fart, sorry) you might do well to contact the author of that module, and work with them until you've got one that behaves itself. It subjects you to a lot of risk, but if you're willing, it may help people with a lot more soundchips than your own. Failing that, /etc/apm/event.d contains is the place to put a file telling it what to do during suspend or resume. pcmcia is already there, a fairly useful example because the cardbus on some systems is touchy the same way. However, you'll want to be clever because if you cause a device-wedge, you won't be able to suspend at all, and the result may be difficult to recover from :( * Heather Stern * star@ many places...
