From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6
Description of problem:
Audio is configured correctly out of the box and working fine.
Playing music with rhythmbox and (less tested) xmms.
When system is under load the sound in rhythmbox sometimes starts "fast forwarding". Stopping and starting the sound will continue at normal speed.
Xmms will sometimes just go silent.
Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1398 (also a few earlier versions)
Steps to Reproduce:
1. have a system with intel sound playing music in rhythmbox
2. set your volume low ;)
3. start a cpu-heavy job (like gcc)
Actual Results: Sometimes, sound will make "fast forward" like sounds.
Expected Results: Music should continue playing like nothing happened.
Got one additional report from fedora-list describing exactly the same problem with this driver.
I see this problem too, however I suspect this has nothing to do with
snd-intel8x0. This is instead the effect of bubbles of nasty scheduling
latency caused by some kernel drivers. For me the airo wireless network driver
with FC4+ kernels causes this problem very often. This didn't happen with FC3.
Are you too using airo networking?
I have an IBM Thinkpad T41, what kind of machine are you using?
Gstreamer (rhthmbox) is reacting poorly to the scheduling latency by somehow
screwing up its timing, causing this fast-forwarding effect. xmms is reacting
in a different poor way, by just stopping. It is a separate bug that gstreamer
is freaking out in this nasty way, so that should be filed separately. Please
refer to this bug when you file that separate bug.
I'm using an Acer Travelmate 8000 with the ipw2200 wireless card (but the
problem happens also when I'm only using wired network).
If it's got nothing to do with the Intel sound driver, I don't understand that
my other FC4 machine (an Athlon64 with SB Audigy) has no problems at all with
rhythmbox. I've never heard it skip. Is the scheduling problem limited to the
Hmm, my Athlon64 using snd_via82xx has never experienced this problem either, so
it is possible that it is limited to snd-intel8x0, and triggered by badness in a
kernel driver somewhere else.
I don't think this has anything to do with the Pentium-M processor. It is most
likely certain kernel drivers that are at fault causing nasty scheduling
latency. This is also triggering a corner case buggy behavior in those audio
software that should be fixed.
I have the same very annoying problem. Both with amaroK (from extras) and rhythmbox. Well... It is pretty
sad not being able to listen to my music while using my computer...
The laptop is an asus V6V, intel8x0 sound, PM processor...
I am also seeing this issue (PIII with snd_ens1371). I suspect an irq sharing
problem between kernel modules (I suspect networking and sound) to be the cause
of this issue, because shuffling IRQ assignments inside of the BIOS provided me
That seems like a reasonable possibility. Klaasjan and/or Jean-Christophe,
please attach the contents of /proc/interrupts from the problematic boxes.
This one is from my laptop:
0: 5394500 XT-PIC timer
1: 116 XT-PIC i8042
2: 0 XT-PIC cascade
6: 1377822 XT-PIC uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4,
yenta, yenta, yenta, eth0
7: 4 XT-PIC parport0
8: 1 XT-PIC rtc
9: 298568 XT-PIC acpi
10: 429769 XT-PIC ipw2200, Intel 82801DB-ICH4, Intel 82801DB-ICH4
Modem, ehci_hcd:usb1, ohci1394
12: 132 XT-PIC i8042
14: 198283 XT-PIC ide0
15: 265479 XT-PIC ide1
Since the problem only occurs under heavy disk load I've been looking at the
hdparm settings. I can make the problem go away by setting the "unmask_irq" flag
on /dev/hda. I guess the (slow) laptop drive causes delays long enough to upset
the sound driver. It's working for me now (tested a few hours).
Maybe the unmask_irq settings was enabled for older kernels? Is there a risk
when I enable this setting?
The risk is minimal IMHO...of course, YMMV... :-) All the 'riskiness'
references seem to involve specific hardware and really old (2.0.x) kernels.
I'm going to move this to WONTFIX since there seems to be a reasonably good
I think I've yelled a little too early. Although the sound doesn't skip as much
as without the unmask_irq setting, I just noticed the problem again. There's
certainly something broken with this sound driver/irq activity/rhythmbox
Please attach the output of running sysreport...thanks!
I have the problem of response slow when there is heavy process such gcc or some
process which access the harddisk frequently.
This does not happen in FC3, any comment or work around?
Created attachment 120048 [details]
sysreport of my affected laptop
I deleted some network service logfiles from the archive (copy of production
data, services are not running on laptop by default).
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
Regrettably, I can still occasionally reproduce the problem (most of the time by
starting an application which triggers high disk-I/O).
I have Intel orignal 915GAV motherboard. Sound card in FC4 is automatically
detected but there is no sound. I use alsamixer & use maximum sound but i can't
Comment 17 sounds like a different issue. Please ensure that you have
un-muted all sound outputs (possibly while leaving "jack sense" muted) and if
the problem persists, open another bugzilla...thanks!
After the last Alsa updates I noticed the following difference: when the system
is under high load the sound sometimes skips, but rhythmbox doesn't go berserk
anymore (music continues to play after a short pause).
There's still a small problem: the first song started after a reboot just
produces clicking. After a song change it sounds fine. No idea if that's related
with the latency problem though.
This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Closed due to lack of respons...please reopen when requested info becomes