Audio latency and realtime performance is critical in any sort of audio producing, recording, remixing, or anything like that.
Saying "I don't know what these people are doing when listenning to music" is just about as a ignorant thing as you can possibly say. It's borderline insulting.
Audio processing is a very intensive realtime thing. Very. It's, in fact, absolutely critical for any sort of digital audio workstation environment. It's as critical as having reliable TCP/IP stack for a web server.
> if you then overload the box, what is the system supposed to stop doing?
Disk I/O for starters. I/O to the video card. I/O to the network. In fact it should absolute halt everything non-critical in a effort to keep the important applications working properly and doing what that particular application requires.
What is critical in a file server is decidely uncritical in audio situation.
You have to understand that we are not just talking about 'overload'.
Humans can perceive audio latency of about 100ms or so. It requires that a audio professional be able to control audio syncing issues down to about that much, give or take. You have to match beats, match vocals, sync audio and video, etc etc.
Take this for example:
I have a MIDI controller. It's a very simple one. Most people would call it a 'keyboard'. But it doesn't play music notes. What it does is that it's a midi controller shaped like a keyboard. I has the traditional piano keys and a few knobs and sliders. It plugs into my Linux box using a USB adapter. It creates a virtual midi device. When I press a key or turn a knob this sends Midi events to the PC.
Midi events are not musical events. They are mearly some sort of 'X happenned' event. Then it's up to various music programs or other midi hardware to interpret that midi event to mean something.
Typically, in Linux, this means using a software synth. A software synth has a number of pre-recorded 'sounds' that play some sort of noise. So my midi keyboard sends that event to the software synth, that synth in turns plays a PCM audio stream that is that particular sound that is then modulated to some sort of note.
Now that noise can be anything. A drum-like noise, a piano, a cat meow, or whatever.
Then I typically route that PCM audio from the software synth through another program that then performs some sort of audio distortion on it. Makes it sound smoother, less digitalized, maybe add some echo or depth or whatever else that I think sounds cool.
This way I can take a noise produced by the software synth and make it sound like, say, a grand piano in a hall or something like that.
Then that modulated PCM audio is then sent to my audio card that then plays the sound out over the speakers.
So the time from when I press the keyboard to the time when I hear the sound will be the total latency:
It's suprisingly complicated isn't it? Even with a somewhat fast computer your looking at continious 60-70% CPU load in many cases just to keep the sound card feed and the audio worker happy. Dual/Quad cores can help a lot, obviously.
And that is a SIMPLE setup. Each step along the way will add it's own small amnount of latency. You want the OS to add as little latency as possible for performing tasks that are not immediately critical for the task at hand. Like it doesn't matter if the disk I/O doesn't happen immediately.. the requirements to keep the sound card buffer feed is a much higher priority in this sort of situation.
So as you can imagine a piano player with a half a second of latency from when they press a key to when they hear a sound is completely unacceptable. It's just shit and will screw them up.
I just play around so I am not critical, but it's certainly unbearable to have a big delay. Like I said that most latency below a 100ms will be generally unpercievable. But a small amount preceived audio latency isn't that bad. After all it takes a while for sound to reach your ears. Sound is kinda slow compared to other things.
Now during the normal operation of Linux there are all sorts of things that introduce latency. The kernel blocks when doing lots of different things and all that happy horseshit.
Having high latency is a good thing, often, in a server. When your dealing with network stuff people expect delays and short pauses when doing stuff so that you can take that into advantage to be able to do your processing tasks in a very fast and efficient manner. Having your system continiously interrupting processes every few milliseconds is going to have a very detrimental effect on overal performance.
If you want to look at it like this:
* High latency behavior == efficient processing == good for servers
* Low latency behavior == desirable behavior == good for digital audio workstations.
On early versions of 2.6 they had system latencies... when the entire system would just pause and be crunching on some task or another for 500ms or so. It'll just blank out, go out ot lunch. Make it impossible for any other application to do any work.
And this isn't even under 'high load' or 'moderate load'. It's just normal operating proceedure. (Obviously huge efforts have been made to improve performance)
When your configuring your audio applications to perform in realtime and you get a lag spike of 250ms or 500ms this does not just cause delay it causes huge problems. It causes audio tracks to fall out of sync. Causes video and audio to go out of sync, which causes performance playback problems and bad video performance as the application struggles to keep things in sync. It causes squaks and pops and other audio artifacts in audio playbacks and audio recordings.
This is a serious problem in other OSes too.
In Windows XP, even though it is very popular, the Win32 API and audio stack is so miserable and realtime performance is so poor that third parties had to create their own driver model for XP called ASIO.
Even with ASIO, though, you have to be very careful about doing disk I/O in Windows to avoid audio latency and the resulting undesirable audio distortions and artifacts. Typically you have to disable your virus protection and things like that.