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/