Playback 10% too fast after resume

[Cedders]

If the laptop hibernates or suspends and then resumes, there is an odd effect when starting (at least) mplayer video and rhythmbox (probably totem and VLC too). Video and audio playback is noticeably too fast: a 5 min song will play in 4min 35sec of real-time, and about a major second out of tune. I'm guessing the sound card clock is set wrongly on resume. Running mpg321 (with default or -o oss or -o alsa09) will reset it so that playback is correct (mpg321 -o esd does not); restarting pulseaudio (not sure the best way to do this) doesn't seem to have any effect, but sudo alsa force-reload also restores to correct pitch/timing.

Ubuntu 9.10 2.6.31-14-generic on Viglen Dossier laptop, soundcard: Intel 82801CA-ICH3 with AD1886

ProblemType: Bug
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: I82801CAICH3 [Intel 82801CA-ICH3], device 0: Intel ICH [Intel 82801CA-ICH3]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: i386
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/dsp', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/pcmC0D1c', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer', '/dev/sequencer', '/dev/sequencer2'] failed with exit code 1:
Card0.Amixer.info:
 Card hw:0 'I82801CAICH3'/'Intel 82801CA-ICH3 with AD1886 at irq 5'
   Mixer name : 'Analog Devices AD1886'
   Components : 'AC97a:41445361'
   Controls : 38
   Simple ctrls : 24
Date: Tue Nov 10 13:47:08 2009
DistroRelease: Ubuntu 9.10
Package: alsa-base 1.0.20+dfsg-1ubuntu5
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: alsa-driver
Uname: Linux 2.6.31-14-generic i686

[Daniel T Chen (crimsun)]

I presume that reloading the sound driver works around this hardware bug?

On Nov 10, 2009 9:10 AM, "Cedders" <email address hidden> wrote:

** Attachment added: "AlsaDevices.txt"
  http://launchpadlibrarian.net/35478132/AlsaDevices.txt

** Attachment added: "ArecordDevices.txt"
  http://launchpadlibrarian.net/35478141/ArecordDevices.txt

** Attachment added: "BootDmesg.txt"
  http://launchpadlibrarian.net/35478156/BootDmesg.txt

** Attachment added: "Card0.Amixer.values.txt"
  http://launchpadlibrarian.net/35478166/Card0.Amixer.values.txt

** Attachment added: "Card0.Codecs.codec97.0.ac97.0.0.txt"
  http://launchpadlibrarian.net/35478177/Card0.Codecs.codec97.0.ac97.0.0.txt

** Attachment added: "Card0.Codecs.codec97.0.ac97.0.0.regs.txt"

http://launchpadlibrarian.net/35478190/Card0.Codecs.codec97.0.ac97.0.0.regs.txt

** Attachment added: "CurrentDmesg.txt"
  http://launchpadlibrarian.net/35478200/CurrentDmesg.txt

** Attachment added: "Dependencies.txt"
  http://launchpadlibrarian.net/35478205/Dependencies.txt

** Attachment added: "PciMultimedia.txt"
  http://launchpadlibrarian.net/35478206/PciMultimedia.txt

** Attachment added: "XsessionErrors.txt"
  http://launchpadlibrarian.net/35478207/XsessionErrors.txt

-- Playback 10% too fast after resume
https://bugs.launchpad.net/bugs/480010You received this bug...

[Cedders (cedric-gn)]

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?)

[Daniel T Chen (crimsun)]

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 .

[Cedders (cedric-gn)]

Daniel T Chen wrote:
> 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

I created a /etc/modprobe.d/options.conf with

  options snd-intel8x0 ac97_clock=44100

and after reloading the driver, the playback was 10% too *slow*. Using

  options snd-intel8x0 ac97_clock=48000

it's correct, but then still 10% too fast after suspend/resume. So I
don't think it's that parameter.

Here are the other parms:

parm: index:Index value for Intel i8x0 soundcard. (int)
parm: id:ID string for Intel i8x0 soundcard. (charp)
parm: ac97_clock:AC'97 codec clock (0 = whitelist +
auto-detect, 1 = force autodetect). (int)
parm: ac97_quirk:AC'97 workaround for strange hardware. (charp)
parm: buggy_semaphore:Enable workaround for hardwares with
problematic codec semaphores. (bool)
parm: buggy_irq:Enable workaround for buggy interrupts on some
motherboards. (bool)
parm: xbox:Set to 1 for Xbox, if you have problems with the
AC'97 codec detection. (bool)
parm: spdif_aclink:S/PDIF over AC-link. (int)
parm: enable:bool
parm: joystick:int

Not sure if it's worth trying any of the others.

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

OK, thanks. That explains it.

> 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 .

Attached. (I thought it might be merely the fact that the driver had a
use count of 1 from pulseaudio [PA} that was relevant. So is the bug in
the driver or PA?)

BTW not surprisingly, the effect is also evident in Flash video.

[Cedders (cedric-gn)]

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 s...

[Daniel T Chen (crimsun)]

Please set the clock rate in /etc/pulse/daemon.conf

On Nov 13, 2009 9:10 AM, "Cedders" <email address hidden> wrote:

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@Audio0changed: 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 de...

[Cedders (cedric-gn)]

Thanks. Putting
  default-sample-rate = 48000
into /etc/pulse/daemon.conf does indeed fix it for PulseAudio (which is practically all I use).

However, a "mpg321 -o alsa" stream is still 10% too fast on suspend/resume, so presumably there is also an issue in the sound driver?

[Cedders (cedric-gn)]

(correction: I meant "mpg321 -o alsa09")

[Brad Figg (brad-figg)]

Hi Cedders,

Please, if you are still having issues, test with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p alsa-base 480010

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds .

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

Please let us know your results.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[markba (mark-baaijens)]

I noticed this behaviour in lucid also. But it is always and in my case it has nothing to do with resume, because I do not resume the machine anyway. The workaround of putting a clock rate of 48000 in /etc/pulse/daemon.conf does not help either.

Maybe this is a new bug?

[Paul White (paulw2u)]

Ubuntu 9.10 (karmic) reached end-of-life on April 30, 2011
Bug report did not expire due to another bug task and bug watch
No reply to request for information almost 9 years ago
Marking "Invalid" to close