What do you mean exactly by "the sound driver"? Sorry, I don't really understand linux sound (particularly PulseAudio). As I mention above, "alsa force-reload" does work around the bug, restoring correct pitch and timing. However, "/etc/init.d/alsa-utils restart" apparently has no effect (probably because pulseaudio is loaded). If I
killall pulseaudio (so can remove the sound driver)
sudo modprobe -r snd_intel8x0
sudo modprobe snd_intel8x0
then that *is* also a valid workaround, yes. I also now notice that if pulseaudio is not loaded and using the snd_intel8x0 module, then suspend and resume does not trigger the bug.
(There was something similar in Hardy that set all mixers to 0 after resume, IIRC again only if the sound driver was actually in use when suspending or hibernating. I may be misremembering. BTW the 10% ratio is approximately that between 48kHz and 44.1kHz - could that be significant?)
What do you mean exactly by "the sound driver"? Sorry, I don't really understand linux sound (particularly PulseAudio). As I mention above, "alsa force-reload" does work around the bug, restoring correct pitch and timing. However, "/etc/init. d/alsa- utils restart" apparently has no effect (probably because pulseaudio is loaded). If I
killall pulseaudio (so can remove the sound driver)
sudo modprobe -r snd_intel8x0
sudo modprobe snd_intel8x0
then that *is* also a valid workaround, yes. I also now notice that if pulseaudio is not loaded and using the snd_intel8x0 module, then suspend and resume does not trigger the bug.
(There was something similar in Hardy that set all mixers to 0 after resume, IIRC again only if the sound driver was actually in use when suspending or hibernating. I may be misremembering. BTW the 10% ratio is approximately that between 48kHz and 44.1kHz - could that be significant?)