Messages in this thread | | | Date | Fri, 23 Jul 1999 11:00:13 -0400 (EDT) | From | Sam Roberts <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
On Thu, 22 Jul 1999, David Olofson wrote: > > Previously, David Olofson wrote in list.linux.kernel: > > > On Sun, 18 Jul 1999 16:47:02 est wrote: > > > For people doing multi-media, there's a class of application where you > > want deterministic priority-driven resource allocation from the O/S, so > > you can use the soundcard drivers, the cd-rom drivers, and the video display > > for streaming media processing, without having your kernel compile make > > it hiccup. > > Yes, I'm very aware of that, and I'm quite interested in that area as > well. But it's outside the scope of the Audiality project, and I simply > decided to use an available solution that works now. Off course, I'll > keep user space real time in mind, and I'll move there when it can > deliver the performance I need.
Sorry. If it gets your job done, great! I just think its an unfortunate limitation of Linux. That Linux is optimized for throughput is great for servers, and thats important. For personal workstations I don't think its great. If you lost 10% performance and gained guaranteed maximum jitters in the 1-3% range, I think that would be great for the multi-media stuff thats becoming more and more part of desktop systems. And make it more useful for soft real-time systems as well.
As for the parts of Linux, like the scheduling alogrithm, that appear to be optimized for multi-user time sharing systems, thats flat-out archaic, in my view. Maybe I'm wrong about this, but when you're the only person at the console, "fairness" in sheduling is a little less necessary: you started the damn thing, if you think its taking up too much time from your sound-card, lower its priority!
> I think this whole discussion is beginning to get confused by different > definitions of "real time". (Not the first time...) Basically, there are > two kinds:
No indeed!
> 1) Soft real time > * Typically ms precision timing. > * No guaranteed deadlines.
I totally don't agree with "no guranteed deadlines", sorry. My last company made remotely operated undersea vehicles (robots... they had manipulators and lots of sensors). Its under water, nothing moves very fast, so 50Hz control frequencies were common. That's 20 ms intervals. However, *guranteed* response to error conditions and hardware failure was required, that response had to be sub-second response, not sub-microsecond, but it *still* had to be guranteed. Its soft realtime, we didn't need 830 ms (+/- 3.25ms), but the O/S heading to sea, flushing its disk cache, and blocking our A/D task for 1 1/2 seconds would make the response noticeably choppy. Not having background data logging impact control loops was also important, even if the loops were only 50Hz. And controls engineers always want faster loops, they're never happy.
> A good multimedia OS would probably support both hard real time and an > intermediate level with low average latency, with reasonable peaks. > Reasonable is NOT 50 ms every now and then! That's the problem with most > OSes. Agreed.
> //David
'ciao Sam
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |