paging, scheduling) than a device driver that runs at elevated IRQL.įinally, note that for the purposes of this article, we’ll ignore certain Windows features such as IRQL PASSIVE_LEVEL interrupt handling and UMDF which, while handy for certain specific uses, are generally unsuitable designs for real-time processing. This means they are more exposed to possibilities of interruptions (e.g.
Latency problems in real-time audio applications occur often as software synthesizers and audio plugins most often have their logic implemented in user-mode. Organ players, for example, must read ahead and hear back what they play with many seconds delay after the air has been processed through the pipes using sophisticated mechanisms and the sound has travelled from the corner of the church to the ear. It’s interesting to note that the problems of latency in real-time applications as well as the “key press before sound” latency problems are ancient and not merely artifacts of the computer era. This means all requests must meet their deadlines. An audio stream must be continuous and any interruption of the audio stream has audible consequences recognized as clicks, pops and drop outs. A common example of an application that has real-time demands is “real-time audio”, such as a software synthesizer that needs to produce sound in response to keys being pressed on a MIDI keyboard with no more than a few milliseconds latency. There exist many types of solutions that may have real-time requirements of some sort, ranging from industrial, medical, military, aviation, research, and high precision to multimedia applications.
This means that every individual request or operation matters. Whereas a solution that is optimized for general purposes cares about things such as average throughput performance, a solution that has real-time requirements instead cares about maximum response times, the worst cases that can possibly lead to a deadline being missed. Windows is designed and optimized with performance and throughput in mind for general purpose uses, not for real-time tasks and low latency, which often have conflicting interests. While Windows is certainly capable of servicing hundreds of thousands of large requests per second, in general, it won’t be able to guarantee that every single request is processed within a specifically defined short time frame. On Windows, all requests to the operating system are processed on a best-effort basis, without any response time guarantee. Often such environments are responsible for handling life critical tasks. In hard real-time environments, by comparison, there is no tolerance for unexpected latencies and missing any deadline means total failure. For soft real-time, responsiveness is highly desired but a missed deadline does not count as total failure. Often, a distinction is made between soft real-time and hard real-time environments. It must offer absolute determinism by giving guarantees of being capable of responding to requests within short time frames. The defining characteristic of a real-time operating system is that it offers predictable execution that can meet deadline requirements. Frequently it comes up when someone runs into trouble trying to write a Windows driver for a device that’s not designed with Windows compatibility in mind, such as a device that expects the software to respond within a short time frame. W indows is not a real-time operating system is a phrase that’s often echoed on the NTDEV forum.