Red Hat Bugzilla – Bug 61974
insane tuxracer sound latency with KDE 3
Last modified: 2007-11-30 17:10:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020314
Description of problem:
There is a tremendous delay in sound with tuxracer, when it's run under KDE 3.
(I set the slider in the KDE 3 personalization wizard to the fast
CPU/effects-laden setting, FWIW.) This latency shows itself particularly badly
when you're picking up herring (you hear the "pop" one or two seconds
afterward!!) and it does not show itself at all if you use GNOME instead of KDE.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Switch to KDE desktop
2. Go through personalization wizard, choose highest effects level (intended for
3. Run Tux Racer.
4. Choose Practice.
5. Start the game (level doesn't matter).
6. Play long enough to run over some of those blue fish, and listen for a delay
(or lack thereof) between the sound and the on-screen action.
8. Switch back to GNOME desktop.
9. Log back in and repeat steps 3-7.
Actual Results: Terrible sound delay in KDE, as described above. (FWIW, it
takes a second or two for the title screen music to start, too...) This delay
does not happen under GNOME however.
Expected Results: I would not expect a trivially perceptible delay in sound
750MHz Dell Inspiron 5000e
ESS Maestro 2E sound
(just in case any of this matters)
There is no sound (SB Live! 5.1) at TuxRacer under GNOME but under KDE there is,
but TuxRacer is terribly slow under both X clients (machine has dual AMD XP1700+).
As for the slow comment, what video card do you have?
A nVidia based Geforce2 card (AsusTec V7700) with default drivers.
I am quite certain that the sound latency delay is due to artsd of KDE. It is
a sound server that runs between KDE applications and the sound device,
allowing for sound mixing that is otherwise not possible because multiple
programs cannot use the OSS device at the same time.
You can reduce the artsd sound latency in the KDE Control Center > Sound >
Sound Server > Sound I/O tab. Reduce the audio buffer size to a small amount
to improve sound latency, but not so low that it causes frequent dropouts.
This works a lot better if artsd is running as a real-time priority. This is
NOT the default in Red Hat Linux probably due to security concerns, because
artsd must be SETUID root in order to do so. I also suspect using the low
latency and/or real-time Linux kernel patches will improve artsd output at low
Your slow graphics in TuxRacer is because your video card is not running with
accelerated 3D. The Open Source nvidia driver does not support it.
Fortunately NVidia frequently releases drivers that work fairly well in Linux,
and they are fairly easy to install. Read the directions and grab the files
If you need any help in installation of those drivers, please visit the AMDMB
Linux forums and the folks there will help with any question you may have.
You will know if the driver installation was successful if when you run
"glxinfo" in an Xterm, it says:
direct rendering: Yes
in one of the output lines.
As a small fix, can the default artsd sound buffer size be decreased a small
bit? I think the current default setting is a bit too conservative.
i decreased the artsd sound buffer size, but it still has sound latency. does it work for
I did some further testing... I'm afraid it isn't safe to reduce the default
artsd buffer size. Even with the default buffer size I get some significant
dropouts during medium levels of activity with scp and compiling at the same
time. I have a fairly fast machine here, so I'm afraid it will be too
unpleasant on slower machines.
The only sure way to reduce the artsd buffer without getting constant dropouts
during other activity is to make artsd run at real-time priority.
Unfortunately that would mean making it setuid root.
If this were Lindows OS, I'd say that would be an acceptable risk.
How much latency do you hear in TuxRacer? I set my artsd to 40ms buffer (-20
nice) and it seems instantaneous to me.
Yes, it is possible to install a nVidia drivers but by doing this will break
up2date. I asked if RedHat could include accelerated drivers but it was turned
down ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62080 ). As RedHat
refuses to include accelerated drivers from nVidia, I expect teuxracer should
perform acceptable even with unaccelerated drivers.
In current state I get 48FPS with glxgears at fullscreen 1024*768*16bit color
and somehow I think even unaccelerated drivers should perform better on dual
AMD XP 1700+.
> Yes, it is possible to install a nVidia drivers but by
> doing this will break up2date.
Installing your 3rd party stuff then manually updating it again later is the
status quo of Linux.
> As RedHat refuses to include accelerated drivers from nVidia,
Red Hat cannot include a closed-source binary hardware driver with their
distribution. Doing so would dramatically increase the risk and liability on
Red Hat's part because if something goes wrong, Red Hat has no way of analyzing
the source code of that portion to know if their kernel or X drivers or the 3rd
party driver is causing a problem.
What if the NVidia driver bug caused mysterious crashes in a seemingly unrelated
mission critical server component? It is a plausible though unlikely scenario
that thousands of dollars of developer time would be wasted trying to hunt for a
bug that cannot be found, nor fixed.
For this same reason the core Linux kernel maintainers added module licensing
symbols to the kernel. You can insert non-open source modules, but the kernel
becomes "tainted". The kernel developers will NOT waste their time trying to
fix a "tainted" kernel.
If you must blame someone, blame nVidia for not providing any open
specifications and/or not releasing open source drivers.
> I expect teuxracer should perform acceptable even with unaccelerated drivers.
> In current state I get 48FPS with glxgears at fullscreen
> 1024*768*16bit color and somehow I think even unaccelerated
> drivers should perform better on dual
> AMD XP 1700+.
Software rendering can only do so much. The CPU doesn't have nearly enough
power to render everything and display things nearly as fast as you think.
That's the whole point behind "Direct rendering" where the GPU takes care of the
graphics crunching and it is sent to directly to the display. It doesn't have
to go through a slow process of the CPU crunching all graphics data, going
through the X software layer then back to the graphics output that "Software
rendering" does. This relies too heavily on the CPU, storing and retrieving
with MUCH slower system RAM, while using MUCH slower indirect X screen writes.
Also your point about having two CPU lightning fast processors makes little
difference in this case. I can say with a high degree of certainty that
glxgears only uses one processor. Try running "top" while glxgears is running
and I bet you both processors will not be 100% busy. tuxracer probably isn't
multi-threading either. The only game I can think of that uses multiple
processors is Quake III, although there may be more in existence now.
I have exactly the same problem as the poster does. I have a bit more
information to contribute, as well.
Sound under ALL of my KDE applications is lagged by about one second. It does
not matter what I am using or how busy the CPU is at the time. The original
poster should try something simple like use XMMS, and see if the visualization
starts a second before the sound does.
I have NO sound in Gnome.
Gnome logs the following to .xsession-errors when I try to use sound:
mcop warning: user defined signal handler found for SIG_PIPE, overriding
arts_init error: can't connect to aRts soundserver
and logs the following in my messages file:
modprobe: modprobe: Can't locate module sound-slot-1
modprobe: modprobe: Can't locate module sound-service-1-0
KDE just logs the first message under .xsession-errors and nothing in
mcop warning: user defined signal handler found for SIG_PIPE, overriding
I also have an NVideo sound card, but I am pretty sure that is a red herring.
I did just add the NVidia drivers, but I should stress I had the same problem
before that (right after my install, for that matter).
Furthermore, my sound was FINE under Redhat 7.2 .
Hopefully these messages mean something to people this bug is assigned to. I
sure would like to have this corrected too. =)
I should clarify that this was under Redhat 7.3, sorry.
I'm still seeing horrible latency with the default KDE settings on Fedora Core
0.94 (which I guess is to be expected). Reducing the latency is causing other
problems (e.g., sound plays at twice the speed but at the same pitch, or sound
only comes out of one speaker).
The non-ALSA maestro driver is buggy enough that I can't tell who is at fault
for what symptoms. (The sound coming out of one speaker is probably the maestro
driver's fault, for instance.) When I get a chance to install ALSA again, so
that an unstable sound driver isn't clouding up the whole situation, I'll retest
this and see if there's still a real problem.
I tested again with kernel 2.6.0-0.test184.108.40.206bkn (i.e, 2.6.0-0.test7.1.52 with
the fix for bug 106867) and anything using 3D acceleration segfaulted (possibly
agpgart related; I'll bugzilla it later if someone else hasn't already). The
artsd problems with low latency settings almost completely disappeared with
ALSA, however. ("Almost" means there's a tiny bit of clicking when the latency
is at the absolute lowest setting, but AFAIK that's not really a bug per se. The
really bizarre stuff with one speaker muted and the speed of the audio doubled
is gone though. There's also FAR FAR less latency with ALSA, at any given KDE
Control Panel setting.)
On my hardware I guess a fix will have to wait until the 2.6 kernel -- until
after Fedora Core 1 -- but things are starting to look better now...
On Fedora Core 2 and different hardware (I no longer have my Dell
Inspiron) I'm able to get things working well if I do the following:
+ Set the KDE preferences so that the sound server sleeps after 1
second (maybe it doesn't need to be that low, but it needs to be a
short amount of time)
+ Then I can run the command "export SDL_AUDIODRIVER=alsa" followed by
"tuxracer", in a Konsole or xterm.
Incidentally, having the sound server sleep so quickly (which is an
option I didn't see in earlier Fedora Core releases) also lets
Chromium run with sound -- this is another problem I had in the past,
but I didn't get a chance to report it.
I'm still thinking about if/how to close this bug (I'll probably have
more comments on that later tonight).
(maybe "when" to close this bug would be a more appropriate word than
Fedora Core 1 has been transferred to Fedora Legacy project. Please upgrade and
close this or move this bug in Fedora Legacy product.
Note that tuxracer was removed from FC and it's replaced by ppracer in Fedora
Extras. You can test it in FC4 test3.