Messages in this thread | | | Date | Thu, 22 Jul 1999 22:24:22 +0200 | From | David Olofson <> | 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.
Well, perhaps I should add that when I said "hard real time", I was actually thinking about guaranteed maximum latencies in the sub ms range... And that's where real time DSP applications belong.
> 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.
> Real-time? Purists may argue not, I don't personally care. > Useful? Hell, yes.
It's real time all right, but IMO, most of those MM applications are closer to soft RT than hard RT. First, for video, latencies an order of magnitude longer than for audio can be accepted. Second; an occasional late video frame may not be the end of the world, but an audio drop-out can come close... ;-)
> 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.
I fully agree. The point with Audiality: Why use restricted, expensive and non-standard DSP hardware when modern UP or SMP workstations can do the job just as well? I think that pretty much places Audiality in the "DSP replacement" area of real time.
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:
1) Soft real time * Typically ms precision timing. * No guaranteed deadlines.
2) Hard real time * Usually significantly better than ms precision * Guaranteed deadlines.
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.
However, taking an entire OS to RTLinux's level of hard real time performance is a waste IMO. Lots of work, more complexity in the kernel, and lost CPU cycles to allow ANY process to get hard real time characteristics, when only a few tasks need it, some of which don't even want to access more than a few special resources.
> 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.
Yep. Pthreads API is in development, and it seems like it's meant to replace the old RTL API in the long run. (At least as long as it doesn't limit RTL performance wise, I'd guess.) As I understand it, the point is partly portability, partly enabling developers to debug and (to some extent, at least) test their applications outside of the dangerous RTL kernel space.
Note that I'm not an active RTL developer, so for more detailed info, you should join the RTL mailing list. (See http://www.rtlinux.org )
Regards,
//David
- 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/
| |