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: Always 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)
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.
barryn: 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. ivo: 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: http://www.nvidia.com/view.asp?PAGE=linux 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. http://www.amdmb.com/vb/forumdisplay.php?s=&forumid=29 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.
warren: i decreased the artsd sound buffer size, but it still has sound latency. does it work for you?
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. DEFERRED?
than: 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.
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. =)
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.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...
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 "if")
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.