Messages in this thread | | | Date | Thu, 22 Jul 1999 14:03:28 -0400 (edt) | From | Sam Roberts <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
Previously, David Olofson wrote in list.linux.kernel: > On Sun, 18 Jul 1999 16:47:02 est wrote: > (...) > > > >Benno, > > > >Having looked at the RT-Linux documentation, my impression was that > >its task programming environment was even more restrictive than that > >for regular device drivers. That doesn't sound like a platform that > >will produce interesting audio applications. > > What are you looking for exactly? What I mean is, real time programming is not, > and will never be the same thing as normal application development. Different > requirements, different rules. I can hardly see what you would want to do from > within a signal processing plug-in that requires that you use anything but the > CPU and the resources of the plug-in host.
Multi-media is an important area that shows the limitations of this kind of thinking. DSP-type real-time applications don't use what they don't have, namely the O/S's device drivers, thus doing similar applications under rtlinux seems perfect, you don't have access to device drivers, and don't miss it.
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.
Real-time? Purists may argue not, I don't personally care. Useful? Hell, yes.
rt-linux is only useful for that class of applications where you could have used a DSP, or some other dedicated micro-controller, communicating with a more O/S featureful host, but want to decrease your expenses ($$ and development time) and do both on a single system. Thats great, but hardly describes all real-time applications, and totally fails for peudo-realtime stuff like multi-media.
Regards, Sam
Btw, have the rt-linux devlopers thought about or implemented the POSIX.4b pthreads API? Then at least you'd have portable code between its threads and other POSIX systems.
- 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/
| |