Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 61974 - insane tuxracer sound latency with KDE 3
insane tuxracer sound latency with KDE 3
Product: Fedora
Classification: Fedora
Component: tuxracer (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
Depends On:
  Show dependency treegraph
Reported: 2002-03-26 10:03 EST by Barry K. Nathan
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-13 05:29:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Barry K. Nathan 2002-03-26 10:03:06 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):

How reproducible:

Steps to Reproduce:
1. Switch to KDE desktop
2. Go through personalization wizard, choose highest effects level (intended for
fastest CPUs)
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.
7. Quit.
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
under KDE.

Additional info:

750MHz Dell Inspiron 5000e
ESS Maestro 2E sound
ATI graphics

(just in case any of this matters)
Comment 1 Ivo Sarak 2002-03-27 04:20:59 EST
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+).
Comment 2 Jay Turner 2002-03-28 15:24:07 EST
As for the slow comment, what video card do you have?
Comment 3 Ivo Sarak 2002-03-29 13:55:51 EST
A nVidia based Geforce2 card (AsusTec V7700) with default drivers.
Comment 4 Warren Togami 2002-04-08 05:04:09 EDT
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    
buffer settings.    
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 
from here: 
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.
Comment 5 Warren Togami 2002-04-08 05:06:04 EDT
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.
Comment 6 Ngo Than 2002-04-09 11:00:14 EDT
i decreased the artsd sound buffer size, but it still has sound latency. does it work for 
Comment 7 Warren Togami 2002-04-12 02:18:02 EDT
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. 
Comment 8 Warren Togami 2002-04-12 02:29:03 EDT
How much latency do you hear in TuxRacer?  I set my artsd to 40ms buffer (-20 
nice) and it seems instantaneous to me. 
Comment 9 Ivo Sarak 2002-04-12 05:24:26 EDT
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+.

Comment 10 Warren Togami 2002-04-12 05:56:25 EDT
> 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.
Comment 11 Need Real Name 2002-06-01 20:23:16 EDT
Good day, 
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 
messages, i.e.: 
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. =) 
Comment 12 Need Real Name 2002-06-01 20:28:59 EDT
I should clarify that this was under Redhat 7.3, sorry.
Comment 13 Barry K. Nathan 2003-10-12 16:26:25 EDT
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.
Comment 14 Barry K. Nathan 2003-10-13 02:51:06 EDT
I tested again with kernel 2.6.0-0.test7.1.52.1bkn (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...
Comment 15 Barry K. Nathan 2004-07-16 00:33:27 EDT
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).
Comment 16 Barry K. Nathan 2004-07-16 00:45:53 EDT
(maybe "when" to close this bug would be a more appropriate word than
Comment 17 Marius Andreiana 2005-05-13 04:37:59 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.