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?

  • 2
    Windows has placed great emphasis on HD audio processing, One of the big critisms of Windows Vista was that it throttled your network connection when listening to an MP3. Everyone complained but MS responded like so: blogs.technet.microsoft.com/markrussinovich/2007/08/26/… – Frank Thomas Feb 12 '16 at 3:55
  • So I would like to know if Android has this problem and why Torvalds can't fix it. Output of kernel version on Android Marshmallow Nexus 9 u0_a83@flounder:/ $ uname -a Linux localhost 3.10.40-gdd82bcf #1 SMP PREEMPT Fri Dec 11 01:21:05 UTC 2015 armv8l – Suici Doga Feb 12 '16 at 4:09
  • 3
    First, you need to understand that the linux kernel, while being flexible, is a general purpose monolithic kernel, designed to work on everything from embedded SOCs to servers with 1024+ CPUs. The workload for HD audio is generally selfish, and does not yeild bus time to other processes, which makes low latency audio processing a strictly desktop issue, and on top of that, most desktop users would not like their PC to freeze while browsing the web, just because there was an audio stream playing. look into the Con Kolivas vs Linus controversy for good discussion on the topic. – Frank Thomas Feb 12 '16 at 4:33
  • are you sure Linux can't do anything on multicore CPUs? Most modern computers have 4< cores – Suici Doga Feb 12 '16 at 6:37
  • 1
    you can look into alternative schedulers for the linux kernel if you want. embedded.com/design/operating-systems/4371651/… its a strenuous exercise though. – Frank Thomas Feb 12 '16 at 6:56

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?.

| improve this answer | |
  • Linux has actually come much closer to being an RTOS with recent merges from the PREEMPT_RT patch into the mainline tree, and there is also the Xenomai dual kernel approach which adds hard real time capabilities to Linux. This is pretty exciting as it allows hard real time to be achieved on various platforms and CPUs, although the exact value of the maximum guaranteed latency will obviously vary. BMW is already using PREEMPT_RT in its autonomous car research. – Groo Jan 1 '19 at 22:16

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.