I often heard the distinction between "soft" real time and "hard" real time, where "soft" essentially means "can be expected to meet the deadline" and "hard" means the real thing, i.e. "is guaranteed to meet the deadline".
This one knows what's up. In embedded or industrial systems there is "soft" real time which means the deadline can be occasionally missed but the system will still be worthy. Or there may be I think what web or app devs do is mostly at this level. Like the "instant" or "real-time" transfer function offered by your bank. Pretty achievable with commodity hardware and software.
And you have "hard" real time which means the system is worthless if it misses a deadline. Like a stock exchange bombarded by HFT orders, a CNC mill or the airbag controller on a vehicle. Now you will need special stuff like RTOS and synchronous ethernet. It's dead serious, like missing a deadline will destroy the company.
I played with the JACK toolkit on Linux which needs a RT_PREEMPT kernel (hard RT where user applications can cut in queue before kernel stuff) which is quite funny, since people are still making good music with a non-RT windows or mac machine. Most likely you won't need hard RT for consumer facing stuff.
And you have "hard" real time which means the system is worthless if it misses a deadline. Like a stock exchange bombarded by HFT orders, a CNC mill or the airbag controller on a vehicle. Now you will need special stuff like RTOS and synchronous ethernet. It's dead serious, like missing a deadline will destroy the company.
I played with the JACK toolkit on Linux which needs a RT_PREEMPT kernel (hard RT where user applications can cut in queue before kernel stuff) which is quite funny, since people are still making good music with a non-RT windows or mac machine. Most likely you won't need hard RT for consumer facing stuff.