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 .
On Tue, Nov 10, 2009 at 11:00 AM, Cedders <email address hidden> wrote: d/alsa- utils restart" apparently has no effect (probably because pulseaudio is loaded). If I
> 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.
> 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 /wiki.ubuntu. com/PulseAudio/ Log .
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:/