Created attachment 301403 [details]
scsrun.log after system-config-soundcard apply

Created attachment 301404 [details]
scsconfig.log output from system-config-soundcard

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.

Is connected to Bugzilla Bug 442397: Radio stream have small interruptions????

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.

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

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

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.

Created attachment 307481 [details]
Output from pulseaudio -vv

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.

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

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

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.

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.

The problem is not fixed in kernel-2.6.25.6-55!

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.

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

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.

kernel-2.6.25.9-76.fc9.x86_64 continues to exhibit the reported bug.

*** Bug 453471 has been marked as a duplicate of this bug. ***

Could you show me lines after 'dmesg | grep intel8x0' just right after boot
(without ac97_clock parameter modification in modprobe.conf)?

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

Tom Tromey: Could you try to add ac97_clock=44100 to modprobe.conf? See comment#17 .

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.

Adding "options snd_intel8x0 ac97_clock=41000" to /etc/modprobe.conf does
temporary fix the problem for me. 

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.

Unfortunately here not. Have to put "options snd_intel8x0 ac97_clock=41000" to
/etc/modprobe.conf...

kernel-2.6.25.10-86.fc9 continues to exhibit the reported bug.

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

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

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

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

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

(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

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.

Created attachment 315232 [details]
Output of alsa-info.sh on my desktop machine

alsa-info.txt attached as requested.

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

Created attachment 315283 [details]
output of alsa-info

Created attachment 315306 [details]
Output of # ./alsa-info.sh --no-upload

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.

(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

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

Created attachment 315343 [details]
Output of # ./alsa-info.sh --no-upload

problems again with 2.6.27-0.377.rc8.git1.fc10.i686.

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

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?

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.

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 
.

Created attachment 321801 [details]
alsa-info.txt for Dell Optiplex GX620

Patch sent to Jaroslav.

Could you please make sure those get merged into rawhide before GA?

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.

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.

D'oh! Forgot to mention: I'm forcing ac97_clock=48000 on that machine.

Created attachment 321870 [details]
0001-Add-whitelist-for-AD1981B-for-AC97-clock-detection.patch

Can we get this patch integrated/sent upstream? I'd like to close this out, at least as far as Fedora 10 is concerned.

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

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

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

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

Ah. kernel-2.6.27.4-85.fc10 includes the whitelist patch:

  * Thu Nov 06 2008 Dave Jones <davej>
  - 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?

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

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.

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.

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

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.