Hi!
Back from vacation, which means I can access the RTL list again, and
post more info about projects with a frustrating lack of available
source code. ;-)
Status
------
I have a Linux/RTLinux driver programming interface module that is ready
for release soon. (That is, in a few days, unless I run into serious
trouble...) The module provides functions that are 90% call compatible
with the kernel calls used in most drivers, which means drivers can be
ported with little more work than search/replace to use the new
functions and data types. Ported drivers will still be usable from
Linux, but (as opposed to my original design) they still run in RT
context (ie may affect RT performance) when used that way. I'll throw in
an option to compile ported drivers using the standard Linux calls,
meaning the ported driver sources will be able to generate standard
Linux drivers, virtually identical to the original versions.
Next
----
Next step is a device manager to add a very basic
open()/close()/read()/write()/... interface for RTL tasks to use.
(driver_register_chrdev() will register the driver with this manager as
well as standard Linux, via suitable interface code - as transparent to
drivers and applications is possible.)
Yodaiken mentioned the minimal POSIX spec for this, and I'd like to know
if there's any work in progress in this area. I know of Comedi, and have
studied the source a bit - looks nice, but a bit too "non-standard" [WRT
existing standard Linux drivers] for my taste... My main goal is to be
able to use existing sound card drivers for my RT audio project, and to
minimize the extra work needed for making new drivers work with RTL. If
it works for other things as well, that's nice bonus! :-)
Other news (for those not on linux-kernel)
------------------------------------------
Interesting stuff is going on around the linux-kernel list. The areas
that cause occasional stalls in soft RT applications have been tracked
down, and Ingo Molnar is working on a patch. AFAIK, the current patch is
slightly unstable, and Linus is not very fond of some of the solutions.
But there doesn't seem to be any severe obstacles doing it the right
way. Linux may become a very high performance multimedia OS very soon,
maybe even beating BeOS at it's own game WRT latency and reliability.
And as an extra bonus; the lower latencies and finer grained locking
improves overall performance and responsiveness as well.
What does that mean to Audiality and similar projects?
------------------------------------------------------
More reliable streaming to/from standard Linux devices, like hard disks.
Note that this is _without_ RTLinux, and the kernel isn't (and will
never be) preemptive, so jitter is still in the ms range, as opposed to
RTL's microseconds.
I'm not moving my project out of RTL, and I still think RTL scheduling
into user space or at least a protected memory option is essential, as
"third party" plugins will have to run in RT context. (Kind of "crash
risk" or "drop-out risk" choice... Neither is acceptable.) My opinion
hasn't changed: Hard real time is an absolute requirement for
professional real time audio, for anything but a
slightly-better-than-Windoze solution. But the improvements on the
standard Linux side will help disk access, user interfaces and similar
things a lot.
And of course, the benchmark results will be good for the world
domination cause! ;-)
//David
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
