Mike Rawlins wrote:
I now have found a most obvious example of the discontinuity. If, before taking off, I grab the title bar of FG window and move window, I hear that nasty sound. Granted, no one does this while flying the sim, but it's the same sound I heard at regular 20-sec intervals while flying, when I had a few other windows active on one or more of my KDE desktops. The problem now seems minor if I have just one shell window open.
Can anyone speak to the relative quality of my NVIDIA
28MB GeForce2 card? I guess I'd like to know if most
linux users run FG with a more expensive video card,
like one that's not a shared memory card.
I can say that your window system runs at a *high* priority so that it will appear "responsive". If you do things that manipulate windows (like resizing or moving them) or do other sorts of interactions with your desktop, you will starve FG of needed CPU cycles. The audio buffer get's fed in little chunks. If the audio chunks are too small, you risk running out of data before the next iteration. If the chunks are too large, you get a delayed response because the old data needs to be played (i.e. engine @ 2500 rpm) before the new data can get played (engine @ 1500 rpm.)
In older versions where we used the plib audio system, we dynamically sized the audio chunks based on your frame rate, but if the frame rate dropped significantly, you could run into situations where the audio buffer got empty, and you'd hear breaks/glitches in the sound.
In the current version of FG we use OpenAL which feeds the audio buffer from a background thread, so in theory this should never happen. I think it still can on rare occasions when something grabs all the CPU cycles for a relatively long amount of time ... this can possibly happen with window system interaction (especially if you have complex windows, transparancy, special effects, etc.) and it can happen on heavy IDE disk IO. (Note that SCSI based disk subsystems are more expensive, but are much smarter and don't hit the CPU to do disk IO, so they have a lot of advantages for things like paging scenery in and out.)
You say that your performance problems are reduced by eliminating other applications and processes, that makes sense to me. :-)
If you only have one CPU, it must be shared across all the processes on your system (run "ps auwx" sometime to see a process list ...) and if you are running a fancy "theme" with lots of decorations/transparency on your windows, your CPU will have to work extra hard to do all the fancy effects as you interact with your window system.
FG runs best if you just maximize the window and don't run anything else on your machine. If you want to run other things at the same time (and I almost always do this on my desktop/development machine) then you just have to live with the performance hits you get from doing other things.
Regards,
Curt.
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-users mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
