Comment 4 for bug 480010

On Tue, Nov 10, 2009 at 11:00 AM, Cedders <email address hidden> wrote:
> 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.

Right, so reloading the sound driver (which is what alsa force-reload
does, which is nearly equivalent to the killall..modprobe -r..modprobe
sequence) does reinitialize the codec/controller, which answers my
question. It looks like you should pass a module parameter specifying
the clock rate (in Hz, not KHz) to snd-intel8x0. It should be fairly
straightforward when looking at:

modinfo snd-intel8x0|grep -i ^parm

The alsa-utils initscript is somewhat misleadingly named. It really
does not do anything to the sound driver other than (re)storing mixer
levels.

> suspending or hibernating.  I may be misremembering.  BTW the 10% ratio
> is approximately that between 48kHz and 44.1kHz - could that be
> significant?)

That is precisely what I'm referring to. The sampling rate correction
apparently requires a reset, but what I'm driving at is whether PA
needs to be restarted. In other words, why does having PA running when
you suspend make a difference? To answer that question I suspect I'll
need output; see https://wiki.ubuntu.com/PulseAudio/Log .