Bug 441087

Summary: Sound/music playing faster than it should on intel chipset
Product: [Fedora] Fedora Reporter: Andrew Farris <lordmorgul>
Component: kernelAssignee: Jaroslav Kysela <jkysela>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: antonio.montagnani, bnocera, dcantrell, hill-robert, james, kernel-maint, naveed, notting, pierre-bugzilla, segg.gill, tromey, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: NEEDSRETESTING
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-14 12:59:22 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 457945    
Attachments:
Description Flags
scsrun.log after system-config-soundcard apply
none
scsconfig.log output from system-config-soundcard
none
pulseaudio-vv-intel-playspeed.txt
none
Output from pulseaudio -vv
none
Output of alsa-info.sh on my desktop machine
none
output of alsa-info
none
Output of # ./alsa-info.sh --no-upload
none
Output of # ./alsa-info.sh --no-upload
none
alsa-info.txt for Dell Optiplex GX620
none
alsa-info.txt from Dell Precision WorkStation 450
none
0001-Add-whitelist-for-AD1981B-for-AC97-clock-detection.patch
none
Test after clocking to 44100
none
Log before Rhythmbox crash none

Description Andrew Farris 2008-04-05 20:04:06 EDT
Description of problem:
Sound/music playing faster than it should on intel chipset.  I'm not sure if
this is caused by driver defaults, gstreamer misbehaving or pulseaudio.  I need
suggestions on what diagnostics may show where the issue is.

This chipset was playing audio correctly during the Alpha phase, but this
machine was clean installed at Beta and I don't know when this issue started (I
generally don't use the intel chipset).  It has been occurring now for at least
2 weeks.  I have tested all of the kernels below and all have the same result.

Version-Release number of selected component (if applicable):
gstreamer-plugins-base-devel-0.10.18-1.fc9.i386
gstreamer-plugins-bad-extras-0.10.6-3.lvn9.i386
gstreamer-debuginfo-0.10.18-1.fc9.i386
gstreamer-plugins-good-0.10.7-1.fc9.i386
totem-gstreamer-2.23.0-6.fc9.i386
gstreamer-plugins-farsight-0.12.6-1.fc9.i386
gstreamer-plugins-bad-devel-0.10.6-3.lvn9.i386
gstreamer-plugins-base-debuginfo-0.10.18-1.fc9.i386
gstreamer-python-0.10.11-2.fc9.i386
gstreamer-plugins-pulse-0.9.5-0.5.svn20070924.fc9.i386
gstreamer-tools-0.10.18-1.fc9.i386
gstreamer-plugins-base-0.10.18-1.fc9.i386
gstreamer-plugins-good-devel-0.10.7-1.fc9.i386
gstreamer-plugins-schroedinger-1.0.0-1.fc9.i386
gstreamer-ffmpeg-0.10.3-3.lvn9.i386
gstreamer-0.10.18-1.fc9.i386
gstreamer-plugins-bad-0.10.6-3.lvn9.i386
gstreamer-devel-0.10.18-1.fc9.i386
gstreamer-plugins-ugly-0.10.7-1.lvn9.i386

pulseaudio-0.9.10-1.fc9.i386
alsa-utils-1.0.16-2.fc9.i386
alsa-plugins-pulseaudio-1.0.16-4.fc9.i386
alsa-lib-1.0.16-2.fc9.i386

kernel-2.6.25-0.121.rc5.git4.fc9.i686
kernel-2.6.25-0.172.rc7.git4.fc9.i686
kernel-2.6.25-0.167.rc7.git2.fc9.i686
kernel-2.6.25-0.177.rc7.git6.fc9.i686
kernel-2.6.25-0.185.rc7.git6.fc9.i686
kernel-2.6.25-0.195.rc8.git1.fc9.i686

How reproducible:
Any audio being played through that device is effected.  Whether sound test or
gstreamer mp3s/wavs.

Steps to Reproduce:
1. Play music (rhythmbox/banshee)
2. Open pavucontrol, move stream from audigy to intel device
3. Audio playback speed/pitch changes between devices

Actual results:
Audio playback speed is too fast.

Additional info:
00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio
Controller (rev 04)
	Subsystem: Dell Unknown device 010d
	Flags: bus master, medium devsel, latency 0, IRQ 17
	I/O ports at d800 [size=256]
	I/O ports at dc40 [size=64]
	Kernel driver in use: Intel ICH
	Kernel modules: snd-intel8x0

Sounds play normally using my SB Audigy card.  The audio played through the
intel device is clearly too fast, causing high pitch vocals (mouse voices).  It
seems to be less than 1.5x increase, just enough to be wrong and noticable.

Smolt: http://www.smolts.org/show?uuid=pub_78677281-8dfd-41a6-86f4-2460453c168d

While running system-config-soundcard I can run the soundtest (playing guitar
strumming) and it correctly plays on both devices.  However,
gnome-sound-properties (playing sinewave test sound) plays differently on both
devices (high on intel).  Even after running system-config-soundcard and
applying changes, any stream through the intel card still plays fast.
Comment 1 Andrew Farris 2008-04-05 20:04:06 EDT
Created attachment 301403 [details]
scsrun.log after system-config-soundcard apply
Comment 2 Andrew Farris 2008-04-05 20:07:15 EDT
Created attachment 301404 [details]
scsconfig.log output from system-config-soundcard
Comment 3 Andrew Farris 2008-05-01 23:41:44 EDT
This is still an issue with kernel-2.6.25-1.fc9.i686, same pulseaudio as above.
 I think that using alsa directly is not doing the same thing as running through
pulseaudio.. if I kill pulse and use system-config-soundcard to configure the
device I can get the guitar strumming test sound to play through both devices
and it sounds the same.

When I start pulseaudio again, I get faster/highpitch sounds out of the intel
device.
Comment 4 antonio montagnani 2008-05-04 12:59:17 EDT
Is connected to Bugzilla Bug 442397: Radio stream have small interruptions????
Comment 5 Andrew Farris 2008-05-06 19:47:37 EDT
Update here on playback speed, its much faster than the 10% I had said before. 
Timing a song 6m10s long, the intel device plays it in 4m20s.
Comment 6 Bug Zapper 2008-05-14 04:57:47 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Lennart Poettering 2008-05-18 15:27:57 EDT
This is most likely not a bug in PA but in ALSA.

Please provide the output of pulseaudio -vv run from the command line.
(terminate a running PA with pulseaudio -k first).
Comment 8 Andrew Farris 2008-05-19 03:39:44 EDT
Created attachment 305911 [details]
pulseaudio-vv-intel-playspeed.txt

In the attachment I start pulseaudio then start banshee, then play a track and
move the output from one device to the other several times.  The playback is
fast for the intel device and normal for sbaudigy.
Comment 9 Chris Wailes 2008-06-02 12:53:40 EDT
Created attachment 307481 [details]
Output from pulseaudio -vv
Comment 10 Chris Wailes 2008-06-02 12:56:16 EDT
I'm having the same problem, as well as several other people over at
FedoraForum.org.  Above is the output of pulseaudio -vv while playing audio from
a flash source.

lspci yields the following line for my audio controller:
00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio
Controller (rev 04)

If you need anything else to help fix this problem I would be glad to help.
Comment 11 Steve 2008-06-05 05:11:59 EDT
I would like to suggest that the priority of this bug to "high" (or urgend)
would be changed. Because many peoples have problems with "intel chipset audio". 
Comment 12 Steve 2008-06-05 05:12:38 EDT
I would like to suggest that the priority of this bug to "high" (or urgend)
would be changed. Because many peoples have problems with "intel chipset audio". 

Please read also here in fedoraforum: 
http://forums.fedoraforum.org/showthread.php?t=189492&page=1&pp=15
Comment 13 Chris Wailes 2008-06-10 15:33:15 EDT
It has just been found that an upgrade from 2.6.24.7-92.fc8 to 2.6.25.4-10.fc8
introduces this problem into Fedora 8 (as noted in page three of that Fedora
Forum thread).  As I'm not sure what changes (if any) the Fedora team makes to
the kernel I don't know if this bug needs to be pushed upstream, or if someone
here can figure out what the problem is.
Comment 14 Lennart Poettering 2008-06-10 16:42:49 EDT
Judging from the PA outputs posted here PA behaves correctly. I am thus very
sure that this bug is in the kernel (or possibly alsa-libs). Reassigning.
Comment 15 Steve 2008-06-18 14:06:05 EDT
The problem is not fixed in kernel-2.6.25.6-55!
Comment 16 Bastien Nocera 2008-06-19 17:39:56 EDT
This is a problem without pulseaudio, and using alsa directly, as well as using
ALSA' oss emulation. This also happens with mplayer, madplay, etc. And on x86-64
here.
Comment 17 Bastien Nocera 2008-06-19 18:00:17 EDT
If somebody wants to try a work-around. In /etc/modprobe.conf:
options snd_intel8x0 ac97_clock=48000

Seems to "fix" it for me. I can't find any recent changes in sound/pci/ac97/ or
sound/pci/intel8x0.c that could be responsible for this though...
Comment 18 Naveed Hasan 2008-06-26 14:28:57 EDT
With the latest updates to Fedora 9, audio is still playing fast on Intel
hardware. If I reduce playback speed to 93%, it sounds just about right.
Otherwise it's chipmunks all around. Will try the workaround posted by Bastien.
Comment 19 Naveed Hasan 2008-07-02 16:55:21 EDT
kernel-2.6.25.9-76.fc9.x86_64 continues to exhibit the reported bug.
Comment 20 Tom Tromey 2008-07-10 10:36:27 EDT
*** Bug 453471 has been marked as a duplicate of this bug. ***
Comment 21 Jaroslav Kysela 2008-07-10 10:49:13 EDT
Could you show me lines after 'dmesg | grep intel8x0' just right after boot
(without ac97_clock parameter modification in modprobe.conf)?
Comment 22 Tom Tromey 2008-07-10 10:54:16 EDT
Here is what I see; I hope this is enough.

intel8x0_measure_ac97_clock: measured 50944 usecs
intel8x0: measured clock 78 rejected
intel8x0: clocking to 48000
Comment 23 Jaroslav Kysela 2008-07-10 11:50:08 EDT
Tom Tromey: Could you try to add ac97_clock=44100 to modprobe.conf? See comment#17 .
Comment 24 Tom Tromey 2008-07-11 15:15:48 EDT
Be warned, I am not a kernel person.
I changed the existing line & added the ac97_clock setting.
Then I rebooted.

The contents of modprobe.conf:

alias eth0 3c59x
alias snd-card-0 snd-intel8x0
options snd-card-0 index=0
options snd-intel8x0 index=0 ac97_clock=44100
remove snd-intel8x0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-intel8x0


This does not work.

opsy. dmesg | grep intel
intel_rng: Firmware space is locked read-only. If you can't or
intel_rng: don't want to disable this in firmware setup, and if
intel_rng: you are certain that your system has a functional
intel_rng: RNG, try using the 'no_fwh_detect' option.

(I'm not sure if this is even relevant; but there is nothing else
interesting.)

Perhaps the index=0 is wrong.  I have no idea what that means...
Let me know if you want me to try another experiment; please be
explicit.  Thanks.
Comment 25 Steve 2008-07-12 05:01:23 EDT
Adding "options snd_intel8x0 ac97_clock=41000" to /etc/modprobe.conf does
temporary fix the problem for me. 
Comment 26 antonio montagnani 2008-07-17 12:19:57 EDT
I am running kernel  2.6.25.10-86.fc9.i686 and my troubles seems gone!!!!
No glitch at all, I have been playing radio streams for about two hours and no
problem at all.
Comment 27 Steve 2008-07-17 12:56:11 EDT
Unfortunately here not. Have to put "options snd_intel8x0 ac97_clock=41000" to
/etc/modprobe.conf...
Comment 28 Naveed Hasan 2008-07-22 04:48:18 EDT
kernel-2.6.25.10-86.fc9 continues to exhibit the reported bug.
Comment 29 Naveed Hasan 2008-07-22 13:49:05 EDT
Adding

options snd-intel8x0 ac97_clock=48000

to /etc/modprobe.conf makes audio streams play at the correct speed on my
desktop system. Without explicitly specifying that, I get a bad clocking number
in neighborhood of around 51000 every reboot, which is just in line with the 7%
speed error I mentioned in
https://bugzilla.redhat.com/show_bug.cgi?id=441087#c18 - here's some data from
/var/log/messages

Jun 24 kernel: intel8x0_measure_ac97_clock: measured 51358 usecs
Jun 24 kernel: intel8x0: clocking to 49489
Jun 26 kernel: intel8x0_measure_ac97_clock: measured 50816 usecs
Jun 26 kernel: intel8x0: clocking to 50098
Jun 26 kernel: intel8x0_measure_ac97_clock: measured 50890 usecs
Jun 26 kernel: intel8x0: clocking to 51630
Jul 21 kernel: intel8x0_measure_ac97_clock: measured 51874 usecs
Jul 21 kernel: intel8x0: clocking to 51207
Jul 22 kernel: intel8x0_measure_ac97_clock: measured 50886 usecs
Jul 22 kernel: intel8x0: clocking to 50232
Comment 30 antonio montagnani 2008-07-25 10:23:44 EDT
I was too optimistic!!! speed problem seems less important, but it still present.
I reverted to a F10 kernel and now it is o.k. 
I wonder why a F10 kernel cannot be downgraded to F9 repository...
Comment 31 Steve 2008-08-15 09:17:18 EDT
Here's another computer with an 'Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller' (on board) which is now playing sounds faster than it should (it was not before this kernel). I'm running kernel-2.6.25.11-97.fc9.i686 now.

Here's some output from syslog:
Aug 14 11:39:24 ArtChaos kernel: intel_rng: FWH not detected
Aug 14 11:39:24 ArtChaos kernel: intel8x0_measure_ac97_clock: measured 50920 usecs
Aug 14 11:39:24 ArtChaos kernel: intel8x0: clocking to 51411
Aug 15 15:04:10 ArtChaos kernel: intel_rng: FWH not detected
Aug 15 15:04:10 ArtChaos kernel: intel8x0_measure_ac97_clock: measured 50868 usecs
Aug 15 15:04:10 ArtChaos kernel: intel8x0: clocking to 51721
Comment 32 Steve 2008-08-17 08:03:36 EDT
(In reply to comment #31)
> Here's another computer with an 'Intel Corporation 82801EB/ER (ICH5/ICH5R)
> AC'97 Audio Controller' (on board) which is now playing sounds faster than it
> should (it was not before this kernel). I'm running
> kernel-2.6.25.11-97.fc9.i686 now.
> 
> Here's some output from syslog:
> Aug 14 11:39:24 ArtChaos kernel: intel_rng: FWH not detected
> Aug 14 11:39:24 ArtChaos kernel: intel8x0_measure_ac97_clock: measured 50920
> usecs
> Aug 14 11:39:24 ArtChaos kernel: intel8x0: clocking to 51411
> Aug 15 15:04:10 ArtChaos kernel: intel_rng: FWH not detected
> Aug 15 15:04:10 ArtChaos kernel: intel8x0_measure_ac97_clock: measured 50868
> usecs
> Aug 15 15:04:10 ArtChaos kernel: intel8x0: clocking to 51721


With the new kernel-2.6.25.14-108.fc9.i686, the sound plays normally again.

syslog:
Aug 17 13:52:26 ArtChaos kernel: intel_rng: FWH not detected
Aug 17 13:52:26 ArtChaos kernel: intel8x0_measure_ac97_clock: measured 50878 usecs
Aug 17 13:52:26 ArtChaos kernel: intel8x0: clocking to 49903
Aug 17 13:56:55 ArtChaos kernel: intel_rng: FWH not detected
Aug 17 13:56:55 ArtChaos kernel: intel8x0_measure_ac97_clock: measured 50042 usecs
Aug 17 13:56:55 ArtChaos kernel: intel8x0: clocking to 48000


And with the old kernel-2.6.25.11-97.fc9.i686 also now.

syslog:
Aug 17 13:52:26 ArtChaos kernel: intel_rng: FWH not detected
Aug 17 13:52:26 ArtChaos kernel: intel8x0_measure_ac97_clock: measured 50878 usecs
Aug 17 13:52:26 ArtChaos kernel: intel8x0: clocking to 49903

How can it be?
Comment 33 Steve 2008-08-22 05:26:46 EDT
The other machine sounds now 'not bad'.

syslog:
Aug 22 11:19:34 localhost kernel: intel8x0_measure_ac97_clock: measured 50932 usecs
Aug 22 11:19:34 localhost kernel: intel8x0: clocking to 41145
Comment 34 Gilles J. Seguin 2008-08-26 14:19:29 EDT
(In reply to comment #23)
> Tom Tromey: Could you try to add ac97_clock=44100 to modprobe.conf? See
> comment#17 .

this setting fix the problem for Dell optiplex GX150 for me
Comment 35 Jaroslav Kysela 2008-08-28 11:51:37 EDT
Thanks for reports. It seems that AC97 clock measuring in intel8x0 code is not perfect. I would like to add a "white table" with predefined rates for your problematic platforms.

Please, could you attach information from "alsa-info.sh --no-upload" script (can be downloaded from http://www.alsa-project.org/alsa-info.sh) to this bug when you set ac97_clock module parameter (see comment#23) to a working value?

Thank you for your help to resolve this problem.
Comment 36 Naveed Hasan 2008-08-28 12:11:40 EDT
Created attachment 315232 [details]
Output of alsa-info.sh on my desktop machine

alsa-info.txt attached as requested.
Comment 37 Gilles J. Seguin 2008-08-28 14:56:50 EDT
(In reply to comment #34)
> (In reply to comment #23)
> > Tom Tromey: Could you try to add ac97_clock=44100 to modprobe.conf? See
> > comment#17 .
> 
> this setting fix the problem for Dell optiplex GX150 for me

Output of alsa-info.sh on my desktop machine

alsa-info.txt attached as requested.
Comment 38 Gilles J. Seguin 2008-08-28 14:58:43 EDT
Created attachment 315283 [details]
output of alsa-info
Comment 39 Steve 2008-08-28 18:00:32 EDT
Created attachment 315306 [details]
Output of # ./alsa-info.sh --no-upload
Comment 40 Jaroslav Kysela 2008-08-29 03:33:09 EDT
Attachments in comment#38 and comment#36 are OK (I'll prepare kernel fix).

Unfortunately, attachment from comment#39 does not contain the ac97_clock module parameter settings (look for ac97_clock in the file generated from alsa-info.sh). Steve, could you tell me which ac97_clock value is right for your machine? I'm not able to determine this value from your previous comments. Thanks.
Comment 41 Steve 2008-08-29 04:12:05 EDT
(In reply to comment #40)
> Attachments in comment#38 and comment#36 are OK (I'll prepare kernel fix).
> 
> Unfortunately, attachment from comment#39 does not contain the ac97_clock
> module parameter settings (look for ac97_clock in the file generated from
> alsa-info.sh). Steve, could you tell me which ac97_clock value is right for
> your machine? I'm not able to determine this value from your previous comments.
> Thanks.

Yes. The value 48000 is right for this machine (Comment #32), but is seems to be perfect now, without writing something to modprobe.conf:

Aug 29 10:05:23 ArtChaos kernel: intel_rng: FWH not detected
Aug 29 10:05:23 ArtChaos kernel: intel8x0_measure_ac97_clock: measured 49849 usecs
Aug 29 10:05:23 ArtChaos kernel: intel8x0: clocking to 48000
Comment 42 Steve 2008-08-29 06:01:06 EDT
(In reply to comment #33)
> The other machine sounds now 'not bad'.
> 
> syslog:
> Aug 22 11:19:34 localhost kernel: intel8x0_measure_ac97_clock: measured 50932
> usecs
> Aug 22 11:19:34 localhost kernel: intel8x0: clocking to 41145

41000 seems to be ok for this machine. Info follows...
Comment 43 Steve 2008-08-29 06:02:03 EDT
Created attachment 315343 [details]
Output of # ./alsa-info.sh --no-upload
Comment 44 antonio montagnani 2008-10-02 16:48:06 EDT
problems again with 2.6.27-0.377.rc8.git1.fc10.i686.
Comment 45 antonio montagnani 2008-10-02 17:09:03 EDT
Oct  2 22:36:12 Casa kernel: intel8x0_measure_ac97_clock: measured 50874 usecs
Oct  2 22:36:12 Casa kernel: intel8x0: clocking to 51387

what shall I do???
Comment 46 Bastien Nocera 2008-10-28 12:57:20 EDT
Oct 27 18:02:17 cookie kernel: ALSA sound/pci/ac97/ac97_codec.c:2122: AC'97 0 analog subsections not ready
Oct 27 18:02:17 cookie kernel: intel8x0_measure_ac97_clock: measured 50916 usecs
Oct 27 18:02:17 cookie kernel: intel8x0: clocking to 51407

kernel-2.6.27.4-47.rc3.fc10.x86_64

Jaroslav, could you tell us whether we'll need to whitelist _all_ the problematic machines (which seems like a lot of work, and a burden on users), or is there any way we could switch to the old (and presumably working) AC'97 clock detection code?

If we'll need to white-list the machines one-by-one, could you please explain how to create a patch for it, so we can see what's already upstream, and whether a particular machine still need to be handled?
Comment 47 Will Woods 2008-10-28 18:19:13 EDT
As far as I can tell the old code just forced the clock to 48000/44100; maybe the algorithm just needs to be a little sloppier? (e.g. accept anything up to ~52000 as 48000)

Definitely still a problem in current F10 snapshots, though.
Comment 48 Jaroslav Kysela 2008-10-29 05:47:02 EDT
The whitelist code is in development 2.6.28 tree (not in rawhide). The GIT commit is http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b3b5485aa96d18b0025dfb2bc92c824dc81a780 
.
Comment 49 Bastien Nocera 2008-10-29 09:01:18 EDT
Created attachment 321801 [details]
alsa-info.txt for Dell Optiplex GX620
Comment 50 Bastien Nocera 2008-10-29 09:04:30 EDT
Patch sent to Jaroslav.

Could you please make sure those get merged into rawhide before GA?
Comment 51 Jaroslav Kysela 2008-10-29 09:47:28 EDT
The patch from comment #48 was updated here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d695e4ea860fc1cbe1e4b101af4e0450219f2db9

.

There is no new clock detection code. This code has not been touched few years. Maybe the msleep(50) call in intel8x0_measure_ac97_clock is not accurate enough in recent kernels, thus automatic AC97 clock detection might get wrong. I hope that it's only for few machines and not for all users.

Also, adding machines to whitelist will make booting a little faster.
Comment 52 Will Woods 2008-10-29 13:36:21 EDT
Created attachment 321827 [details]
alsa-info.txt from Dell Precision WorkStation 450

Here's some alsa-info. I really hope we don't need to whitelist (and patch the kernel) for every single affected machine.
Comment 53 Will Woods 2008-10-29 17:16:02 EDT
D'oh! Forgot to mention: I'm forcing ac97_clock=48000 on that machine.
Comment 54 Bastien Nocera 2008-10-29 17:35:57 EDT
Created attachment 321870 [details]
0001-Add-whitelist-for-AD1981B-for-AC97-clock-detection.patch
Comment 55 Bill Nottingham 2008-11-04 13:21:01 EST
Can we get this patch integrated/sent upstream? I'd like to close this out, at least as far as Fedora 10 is concerned.
Comment 56 antonio montagnani 2008-11-08 03:44:47 EST
for your information I tested 2.6.27.5-88.fc10.i686 and I am experiencing still breaks and rewind in playing radio streams, that disappear when I use:
 options snd-intel8x0 index=0 ac97_clock=44100

With 48000 sound is good but not completely smooth, I hear some hicups now and then
Comment 57 antonio montagnani 2008-11-08 13:23:42 EST
Created attachment 322960 [details]
Test after clocking to 44100

options snd-intel8x0 index=0 ac97_clock=44100

sound has improved but very small interruptions still here (not really interruption, I do not know how to describe them due to my poor english..)
If you look to the log you will see some hundreds of byte to be rewound...not thousands when clock was standard.

I do not know if this can help
Comment 58 antonio montagnani 2008-11-08 15:08:31 EST
Created attachment 322965 [details]
Log before Rhythmbox crash

I don't know if it can help, but this is extended log, and at a certain point Rhythmbox crashed...I suppose due to pulseaudio problems
Comment 59 Will Woods 2008-11-08 19:19:25 EST
Okay, but that's not "sound/music playing faster than it should", so it's a different bug.

Bastien, did this patch make it upstream (or into our kernel?)
Andrew, are you still having this problem with the current rawhide kernel (kernel-2.6.27.4-68.fc10 or later)?
Comment 60 Will Woods 2008-11-10 16:24:01 EST
Ah. kernel-2.6.27.4-85.fc10 includes the whitelist patch:

  * Thu Nov 06 2008 Dave Jones <davej@redhat.com>
  - alsa: implement ac97_clock whitelist (#441087)

Andrew, can you please retest using that kernel (or a newer one) and report whether it plays sound at the proper speed/pitch?
Comment 61 antonio montagnani 2008-11-11 19:29:10 EST
well....I suggest to grab alsa-lib-1.0.18-7.fc10.i386 from koij and retest.
My problems seems gone.
No interruptions no underruns...
Comment 62 Will Woods 2008-11-12 15:36:07 EST
For the record, kernel-2.6.27.5-101.fc10.i686 is working fine for me, at least in terms of getting the ac97_clock (and thus pitch/speed) right.

Interruptions/underruns are a separate issue.
Comment 63 Will Woods 2008-11-14 12:59:22 EST
Seems to work for everyone affected. Closing.

Reopen this bug *only* if you have an ac97 audio chipset and your sound is playing faster/higher-pitched than it should.
Comment 64 Bob Hill 2008-11-25 12:52:09 EST
Running a multi-boot desktop with the following sound hardware:
        Multimedia audio controller:
        Intel Corporation 82801BA/BAM AC'97 Audio Controller (rev 02)
        Subsystem: IBM Netvista A40/A40p
        Flags: bus master, medium devsel, latency 0, IRQ 17
        I/O ports at f000 [size=256]
        I/O ports at f400 [size=64]
        Kernel driver in use: Intel ICH
        Kernel modules: snd-intel8x0

Booting F9  (kernel-2.6.27.5-41.fc9.i686)  shows these (good) messages in
dmesg, and then sound plays back at a correct-sounding speed and pitch:
        intel8x0_measure_ac97_clock: measured 50775 usecs
        intel8x0: clocking to 41134

Booting newly-installed F10  (kernel-2.6.27.5-117.fc10.i686)  shows these
(bad) messages in dmesg, and then sound plays back too fast and too tinny:
        intel8x0_measure_ac97_clock: measured 50917 usecs
        intel8x0: measured clock 78 rejected
        intel8x0: clocking to 48000

The problem has been circumvented in F10 by adding the following statement to
/etc/modprobe.d/modprobe.conf.dist:
        options snd-intel8x0 ac97_clock=41194
(Using 41194 instead of 41134, as per various recommendations in internet.)
Comment 65 Bob Hill 2009-01-28 05:17:29 EST
This problem has now been fixed, in kernel-2.6.27.12-170.2.5.fc10.i686.
The circumvention in the last comment (2008-11-25) is no longer needed.