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. There's no full blown OS available to plug-ins running on dedicated DSP systems... User interface code and the like certainly DOES NOT belong in real time space at all. So, what's the problem?
Off course, it would be nice to be able to program real time applications using a subset of the standard API in user space, and being able to use the standard drivers. But when will standard Linux become a hard real time OS?
My guess: Not very soon. Efficient use of system resources for maximum average throughput does not go well together with hard real time requirements...
OTOH, the level of hard real time performance delivered by RTLinux is really a bit of overkill for real time audio (even though it does make a few things a bit easier), so "standard" Linux real time may be good enough when the splinlock problems have been cleaned up a bit more. Audiality might move there when that happens.
But it's hard real time or nothing. Not a missed deadline, ever. Or any serious users that need to do live recording and/or real time processing will simply have to stay with (expensive, proprietary, non hackable) dedicated DSP systems. I just think that's a terrible waste of affordable CPU power and good sound cards.
>My current understanding is that acheiving our audio latency goals
>depends on two things at the moment:
>
>1) Less locking in the kernel. I understand that this is slowly
>coming about, but I'd like to be able to better track what can be
>expected when. Measuring where things are *now* is aided by programs
>such as your latencytest.
>
>2) HZ > 100. This is so we can have something other than monolithic
>programs that open and get their timing from the soundcard.
>Apparently, this is easy to do now, but I wonder when it will
>mainstream and be available in some distributions.
Yeah, this looks like steps in the right direction but, will 1) quarantee that real time deadlines will ALWAYS be met (provided the tasks are correctly designed, off course? And 2) sure makes it possible to improve timing precision. But I still think true pre-emptive task switching is the way to go for real time, as any form of "long" latencies will reduce the maximum real time load you can put on the CPU before deadlines are missed. For example, if a latency of twice the task switch granularity is required, you can only use about 50% of the available CPU power, at the very best...
>Best of Real-Time,
>
>Eric
>
Regards,
//David Olofson
PS. Will post a brief technical explanation of my ideas, pros/cons of using RTL and so on. Might clear a few misconceptions out, or might give me some hints that puts me on the right track... ;-)
Angelfire for your free web-based e-mail. http://www.angelfire.com
-
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/