Red Hat Bugzilla – Bug 444316
ac97_clock isn't properly set on some intel sound cards
Last modified: 2009-01-30 21:21:46 EST
Users will experience heavily tinny sound because for whatever reason the module
assumes an ac79_clock of >48000 usecs.
The fix for this has been to set this manually in /etc/modprobe.conf, but
realistically, this shouldn't need fixing by the user.
For now, filing under kernel because this is a kernel module's setting.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Is it possible that this bug was fixed at some stage in F9, but then later
re-introduced back into F10? (Possibly by the F10-fix for bug 441087??)
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-184.108.40.206-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 F10 (kernel-220.127.116.11-120.fc10.i686) shows these (bad) messages in
dmesg, and then sound plays back too fast and too tinny:
intel8x0_measure_ac97_clock: measured 50913 usecs
intel8x0: measured clock 78 rejected
intel8x0: clocking to 48000
The problem has been circumvented in F10 by adding the following statement to
options snd-intel8x0 ac97_clock=41194
(Used 41194 instead of 41134, because of various internet recommendations.)
As stated by Will Farrington above, a user should not really be expected to
have to resort to this kind of circumvention to get sound working properly,
and it would be nice if this problem could be fixed in F10, as it is in F9.
This problem has now been fixed, in kernel-18.104.22.168-170.2.5.fc10.i686.
The circumvention in the last comment (2008-11-20) is no longer needed.