Here are a few more possible clues. There's what may be a related bug at https://bugzilla.redhat.com/show_bug.cgi?id=496119 . Perhaps either the fix in 2.6.30 was incomplete or actually caused this suspend/resume problem. (Also as mentioned adding the options line has no effect on the bug, presumably because it only takes effect on module load, not resume). The clock measurement seems fine for me: Nov 10 12:40:57 laptop23 kernel: [ 18.584052] intel8x0_measure_ac97_clock: measured 54053 usecs (2598 samples) Nov 10 12:40:57 laptop23 kernel: [ 18.584061] intel8x0: clocking to 48000 But this same setting of the clock does not seem to happen on resume after which I get similar symptoms to those in the Red Hat report (i.e. too fast). Is there any way to print the current values of the clock registers on the card? This is what PulseAudio does during suspend and resume: lI: main.c: Got signal SIGUSR2. I: module.c: Loaded "module-cli-protocol-unix" (index: #17; argument: ""). I: alsa-sink.c: Increasing wakeup watermark to 80.00 ms I: client.c: Created 3 "UNIX socket client" D: cli.c: CLI got EOF from user. I: client.c: Freed 3 "UNIX socket client" I: client.c: Created 4 "UNIX socket client" D: alsa-sink.c: Requested to rewind 65536 bytes. D: alsa-sink.c: Limited to 47144 bytes. D: alsa-sink.c: before: 11786 D: alsa-sink.c: after: 11786 D: alsa-sink.c: Rewound 47144 bytes. D: sink.c: Processing rewind... D: source.c: Processing rewind... I: module-device-restore.c: Storing volume/mute/port for device sink:alsa_output.pci-0000_00_1f.5.iec958-stereo. D: cli.c: CLI got EOF from user. I: client.c: Freed 4 "UNIX socket client" I: client.c: Created 5 "UNIX socket client" D: cli.c: CLI got EOF from user. I: client.c: Freed 5 "UNIX socket client" I: client.c: Created 6 "UNIX socket client" I: module-device-restore.c: Storing volume/mute/port for device source:alsa_input.pci-0000_00_1f.5.analog-stereo. D: cli.c: CLI got EOF from user. I: client.c: Freed 6 "UNIX socket client" D: alsa-source.c: Read hardware volume: 0: 42% 1: 42% I: client.c: Created 7 "UNIX socket client" D: sink.c: Suspend cause of sink alsa_output.pci-0000_00_1f.5.iec958-stereo is 0x0001, suspending I: alsa-sink.c: Device suspended... D: source.c: Suspend cause of source alsa_input.pci-0000_00_1f.5.analog-stereo is 0x0001, suspending I: alsa-source.c: Device suspended... D: reserve-wrap.c: Device lock status of reserve-monitor-wrapper@Audio0 changed: not busy D: cli.c: CLI got EOF from user. I: client.c: Freed 7 "UNIX socket client" D: module-udev-detect.c: /dev/snd/controlC0 is accessible: yes I: module-suspend-on-idle.c: Source alsa_input.pci-0000_00_1f.5.analog-stereo idle for too long, suspending ... I: module-suspend-on-idle.c: Sink alsa_output.pci-0000_00_1f.5.iec958-stereo idle for too long, suspending ... I: module-device-restore.c: Synced. I: client.c: Created 8 "UNIX socket client" D: cli.c: CLI got EOF from user. I: client.c: Freed 8 "UNIX socket client" I: client.c: Created 9 "UNIX socket client" I: module-device-restore.c: Storing volume/mute/port for device sink:alsa_output.pci-0000_00_1f.5.iec958-stereo. D: cli.c: CLI got EOF from user. I: client.c: Freed 9 "UNIX socket client" I: client.c: Created 10 "UNIX socket client" D: cli.c: CLI got EOF from user. I: client.c: Freed 10 "UNIX socket client" I: client.c: Created 11 "UNIX socket client" I: module-device-restore.c: Storing volume/mute/port for device source:alsa_input.pci-0000_00_1f.5.analog-stereo. D: cli.c: CLI got EOF from user. I: client.c: Freed 11 "UNIX socket client" D: alsa-source.c: Read hardware volume: 0: 42% 1: 42% I: client.c: Created 12 "UNIX socket client" D: cli.c: CLI got EOF from user. I: client.c: Freed 12 "UNIX socket client" Apparently nothing relevant. I don't think it's related to PA as such. If I kill pulseaudio, then use mpg321 to play back through the "-o alsa" device and suspend and resume, playback continues at the correct pitch/speed. If I play back using "-o alsa09" or "-o oss" then, after resume, playback is too fast (and continues to be when I restart pulse-session; restarting PA doesn't fix it; starting an application that uses ALSA does). So could it be something to do with restoring instances of open devices that use snd_intel8x0 only once?