Originally posted by phred14
View Post
This is done by making the system switch contexts much faster and/or by allowing certain processes to interrupt anything else in the system.
More times you switch contexts and the more times processes get interrupted then the slower the overall performance will be. When the kernel must switch rapidly between processes then cache in the CPU gets invalidated. Main memory is much slower then cpu cache so much so that you can spend a significant number of your cpu cycles just filling up the cache.
Therefore when everything else is equal a very responsive system is going to be slower then a system that has poor response. Slower as in taking longer to do actual work.
But this is going to matter most on a busy system.
Low latency is important for audio work because you are building a system to interact with in real time. That is when you press a button on your midi synth you want to be able to hear it right away. When you are playing with a band you don't want the music you are playing to be all of a sudden off by 200 msecs because some system process decided it was time to flush the file system cache out to disk. This also can result in buffer underruns for realtime music... meaning your system has temporially ran out of information to give to your sound card and that results in skips, scratchy sounds, pops, and other audio artifacts. If you are doing live recording with multiple inputs it can be important to keep them all in sync.
This is important because you will have a lot going on at your system at the same time. Reading in Midi data over USB, writing out midi data over midi connections, software synths processing realtime, sample loops playing, jackd running, and all sorts of other things in addition to your normal system processes. etc etc.
A normal kernel cannot guarantee that it can go through all the processes in and do enough work to keep everything flowing at 30msec response rate. It doesn't matter how fast it is, it's just not setup to allow that because it's designed for best efficiency. Now with a realtime kernel you can still fall short, but that should technically be because your system just isn't fast enough.. not that the kernel failed to keep everything running properly for a quarter of a second.
Now with video games you have a single process going flat-out. You are going to let that process be dominate and not much else is going to be going on. You can pretty much get the same effect as running a realtime kernel as just raising the process priority of X and your video game above anything else and not get the hit that you'd get from using a rt kernel.
Leave a comment: