Why does Windows not need a low latency or real time kernel?

Question

All Linux distros have problems with latency when audio recording, gaming, etc. But the Windows kernel can be used for audio recording, gaming or anything without a delay.

Why does Windows not need a low latency or real time kernel or is it already one?

Answer 1

Neither Windows nor Linux is anything close to a real-time operating system (RTOS) and as far as I know, neither can be made to be so. The goals, requirements, and philosophies of RTOS versus general-computing differ too fundamentally for any one product to usefully answer both.

You simply can't risk having the vagaries of interrupt timing affect the behavior of anti-lock brakes or send a $2B Mars rover careening off a cliff... but prioritizing the relevant design necessities involves significant overhead that would, in general, be wasted on desktop computing scenarios.

As others have noted on this page, if some general-computing operating system happens to perform well on real-time tasks (such as those you mention), its likely just due to a lot of dreary empirical testing, profiling, and tuning work by the OS vendor. I say 'dreary', because those underlying real-time factors make progress in the tuning effort inherently non-deterministic.

As you can imagine, that's a wholly different universe from one where the entire software stack can fundamentally rely on maximum latency guarantees established by an RTOS. These maximums, which aggregate as deterministic "low-latency" overall, are incorporated into the very definition of RTOS correctness, meaning that a late result becomes "impossible" with properly working hardware. Timing errors either provably can't happen or become moot (perhaps because preconditions can't arise, etc.) and any such error is considered a total failure equally as wrong or inconceivable as obtaining 2 + 2 = 5.

Related: What does "Windows is not a real-time operating system" mean?.

Answer 2

You state "the Windows kernel can be used for audio recording, gaming or anything without a delay".

There is in fact a delay, so what you really mean is "without a delay that is perceptible or troublesome to humans". The delay is unavoidable, but the size of the delay is what determines a system's suitability for "interactive" use.

---

There has been a lot of work put into low-latency audio frameworks - for example Windows' ASIO, and Linux's JACK. These typically involve removing layers of abstraction, reducing buffer sizes, etc...

Media playback is just about synchronising the audio and video elements, the buffers can be huge so long as the playout is coordinated correctly.

Gaming and Pro Audio Recording require streams to be built on-the-fly depending on external factors like user input.

---

The topic of "Real-Time Computing" has no real place when discussing human interaction with systems - we are very lenient and our brain can handle relatively large offsets between our senses - for example audio and video.

Real-Time systems provide guarantees - for example if a trigger input occurs, computation will complete and output will occur within n microseconds. This is crucial for correct operation of many systems - often with life or death consequences.

The significant additional effort involved in providing such guarantees - in design, implementation and verification - is simply not justifiable to make sure that your game feels immersive - not to mention that such systems are often orders of magnitude simpler as a side effect of assuring the guarantees are met.