Red Hat Bugzilla – Bug 444388
Sound lag issues with pulseaudio
Last modified: 2009-12-18 01:07:44 EST
Description of problem:
Sounds lag while playing armacycles-ad/armagetron-ad. All possible variations of
quality / buffer size / sound sources tried, with no significant improvement.
(Low quality lags the least, but sounds horrific).
For example, certain sound effects, such as turning, don't play right away, and
appear to be buffered one after another, so that shortly into the game, this
"sound lag" for the turning quickly becomes a sort of constant, repetitive,
ticking sound. Even if only two people turn at the same time, it sounds like a
"tick-tick" one after another.
This issue did NOT occur in Fedora 7, but I have noticed the problem in Fedora 8
(i386 AND x86_64), and Fedora 9 (Pre-release, i386), so I'm pretty sure it's a
PulseAudio related bug.
Version-Release number of selected component (if applicable):
output of rpm -qa | grep SDL (in case it's relevant)
output of rpm -qa | grep pulseaudio (in case it's relevant)
Steps to Reproduce:
1. Install armacycles-ad into "clean" Fedora 8 or 9 install (currently confirmed
with Fedora 9 pre-release, haven't tried Fedora 8 recently)
2. Play multi-player Internet game (most noticeable in multi-player Internet
game, but still tiny bit of delay with sounds in single player local game).
3. Turn and listen to sound effects.
Sound effects seem to be buffered (queued) and played one after another,
resulting in a constant repetitive ticking.
Sound effects should play right away when turning, and not delayed until a
previous effect has completed.
Hardware I'm using is snd_hda_intel (ICH7)
output of /sbin/lspci (if needed; NOTE: I'm using a Dell Inspiron E1405)
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT
Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML
Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition
Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE
Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
02:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network
Connection (rev 02)
I see this too, with different hardware. Do you see this on any other SDL games?
I don't know, but I can test a few, if you can provide me with the names of some
in the Fedora repos.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
I see this on a different hardward. Emu10k1.
Hi, Jon Ciesla, Fedora maintainer of "Armacycles-AD" .:)
I've got a bug report concerning sound lag in Armagetron using Pulseaudio.
Several of us see it on different hardware. Have you encountered this, or have
Whoops, accidentally closed, sorry.
No word from upstream. Just wanting to check if you're still seeing this before Inag them again.
I haven't played the game in awhile to be sure, but I suspect the issue remains, as I haven't heard a solution yet. I also suspect that this is most likely a Pulseaudio bug, as it didn't happen in Fedora 7. I don't know if this planned feature for F10 is related: https://fedoraproject.org/wiki/Features/GlitchFreeAudio
Ok, I'll assign it to Pulseaudio, see if they can help.
Now that PulseAudio 0.9.12 has been released (which presumably includes the glitch-free sound patches that were integrated into 0.9.11), will we be seeing a release for Fedora 9, or is it only going to end up in Fedora 10? Koji shows some successful builds of PA 0.9.12 for F10, so presumably it wouldn't be too difficult to build some for F9 users who are experiencing these problems?
*** Bug 444924 has been marked as a duplicate of this bug. ***
I'm getting the same problem -- glitches, lags, and crashes -- with rhythmbox, xmms, and other sound apps on Fedora 9 x86_64.
# uname -r
# lspci | grep Audio
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia
I have recently installed FC10 and get the same lag issues with pulseaudio.
$ uname -r
$ lspci | grep Audio
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
Update: I had similar problems with audio lagging in F10 also. I don't know if this fix works for F9, but adding my user to the realtime pulseaudio group (pulse-rt) seemed to fix most of my sound issues in Fedora (aside from the occasional broken snd_hda_intel alsa drivers that get rolled into kernels pushed to stable before they are fully tested on this hardware, of course).
Solution: add user(s) to pulse-rt group
(In reply to comment #13)
> I have recently installed FC10 and get the same lag issues with pulseaudio.
> $ uname -r
> $ lspci | grep Audio
> 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
> Controller (rev 02)
That kernel has a known issue with that intel chipset. update to the latest: 188.8.131.52-170.2.5.fc10.x86_64 (see Bug 477954 to track that issue).
(In reply to comment #14)
> Update: I had similar problems with audio lagging in F10 also.
I've just installed F10, and noticed audio "tearing" in Rhythmbox, and a bit of audio lagging too.
> [..] adding my user to the realtime pulseaudio group
> (pulse-rt) seemed to fix most of my sound issues in Fedora [..]
Another thing to try is to give PulseAudio authorisation to run in real-time and to reduce its nice level. You can do this through the "Authorisations" tool in GNOME (System -> Preferences -> System -> Authorisations). I've just tried this, and checking PA in System Monitor shows that it now has a negative nice (once I've rebooted) which should improve audio quality.
I haven't done extensive testing yet, but it did seem to fix the audio "tearing".
(In reply to comment #16)
> Another thing to try is to give PulseAudio authorisation to run in real-time
> and to reduce its nice level. You can do this through the "Authorisations" tool
The pulse-rt group has the appropriate authorizations for this already, which is why it's just easier to add somebody to that group rather than mess with the authorizations.
In reality, this is still sort of a bug, because it shouldn't be necessary to gain niceness and realtime authorizations to play audio with totem or any other app, especially when no other apps are running on a 2GHz Core2Duo with HDAIntel audio. But it's a quick fix anyway, regardless of the method you go about enabling the realtime authorization.
Perhaps next time, something as "experimental" as pulseaudio won't be rushed in to replace the stuff that works just fine already? (Granted, the concept is nice, but it wasn't ready for F8, F9, and still isn't ready in F10).
Well, despite adding my user to pulse-rt and giving PulseAudio authority to elevate itself and run as real-time, it doesn't appear to have made much difference - I'm still experiencing jumping and tearing in my audio in Rhythmbox.
To a certain extent, it is better than F9 in that it doesn't just drop out, but it is still annoying that this bug hasn't been fixed yet...
My stats, since I don't think I've posted them since I updated my system:
uname -r => 184.108.40.206-170.2.5.fc10.i686
lspci | grep Audio => Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
rpm -q pulseaudio => pulseaudio-0.9.13-6.fc10.i386
(In reply to comment #18)
> Well, despite adding my user to pulse-rt and giving PulseAudio authority to
> elevate itself and run as real-time, it doesn't appear to have made much
> difference - I'm still experiencing jumping and tearing in my audio in
> To a certain extent, it is better than F9 in that it doesn't just drop out, but
> it is still annoying that this bug hasn't been fixed yet...
I had a similar problem with totem-xine, but I updated to pulseaudio-0.9.14-1.fc10.i386 from the updates-testing repository (yum --enablerepo=updates-testing update pulseaudio) and everything seems fine.
However, in any app, I still get some slight "tearing" in audio in the first few seconds of anything I play.
(In reply to comment #19)
> I had a similar problem with totem-xine, but I updated to
> pulseaudio-0.9.14-1.fc10.i386 from the updates-testing repository (yum
> --enablerepo=updates-testing update pulseaudio) and everything seems fine.
> However, in any app, I still get some slight "tearing" in audio in the first
> few seconds of anything I play.
I decided I'd do the same as you, but unfortunately it hasn't fixed my problems with the audio "tearing".
Is this bug about lag or about initial crackling? If it's about lag, does it still happen?
(In reply to comment #21)
> Is this bug about lag or about initial crackling? If it's about lag, does it
> still happen?
When I initially reported the bug, my main concern was about the sound artifacts in armacycles-ad/armagetron-ad. However, the pulseaudio problems I experienced caused me to stop playing that game. (It may be useful for somebody to test that program after the F11 general release.) I'm not really sure how best to describe the problem, but perhaps the phrase "rhythmic echoing that appeared to be a burst of audio delayed from game audio events" (i.e. sounds that should have been played were not played on time and scheduled to burst simultaneously at a later time, and at regular intervals, when several sounds were queued).
Some people have reported that adding the user to pulse-rt group helped a bit (but this should NOT be necessary for basic game or audio usage). For me, this problem helped fix similar "bursts" of static in totem-xine while playing movies.
In my opinion, the bug persists because of two primary problems (which may be related):
1. any app that uses audio, loses the first 1-2 seconds when started (or resumed, if previously paused).
2. improper scheduling/timing causes frequent skips, static, bursts, artifacts, etc.
I don't know the programming details, so I can't desribe much more, but for me, on my basic Dell laption with Intel Core2 Duo configurations (845GM and 865GM, one of each), these problems shouldn't exists, as performance is not a concern. However, ever since pulseaudio was introduced, I've continued to experience these problems.
That was a long answer, but a shorter answer probably would be "both", and yes they still happen (although the lag doesn't happen as often in the pulse-rt group, but I really shouldn't have to put users there to get basic playback to work correctly).
I fear that after comment #12 or so, this bug became too general to be properly triaged. I'm inclined to suggest that for the purpose of this bug, we consider only the original issue - the sound artifacts in armacycles-ad/armagetron-ad.
Can anyone report whether or not this specific problem remains with recent pulseaudio?
And, if anyone has a specific issue with sound problems in other apps, please start a new bug and include specific information including kernel version, alsa-libs version, sound card model and kernel module used, and any pertinent information about the pulseaudio configuration.
I am experiencing this "sound lag" bug in Fedora 11.
I apply all stable updates. So I assume most-recent PulseAudio default setup.
When I play Quake 4 (Linux compatible game), sometimes the sound will lag.
This was never a problem in Fedora 9, but happens semi-regularly in Fedora 11.
Everything will be fine, then a glitch / pause / etc...
After that, all sounds have ~1 second delay.
If I quit / restart game, sometimes it fixes, sometimes not.
Usually I need to logout-login, then sounds are normal for a while.
I know that Quake 4 was "released" before PulseAudio, so it could be an application-specific issue.
As requested, I may open a new bug for this.
Feel free to send me information about what logs / commands I should post.
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.