lkml.org 
[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: real-time threaded IO with low latency (audio)
On Thu, 22 Jul 1999, David Olofson wrote:
> > Previously, David Olofson wrote in list.linux.kernel:
> > > On Sun, 18 Jul 1999 16:47:02 est wrote:
>
> > 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.

Sorry. If it gets your job done, great! I just think its an unfortunate
limitation of Linux. That Linux is optimized for throughput is great
for servers, and thats important. For personal workstations I don't think
its great. If you lost 10% performance and gained guaranteed maximum
jitters in the 1-3% range, I think that would be great for the multi-media
stuff thats becoming more and more part of desktop systems. And make it
more useful for soft real-time systems as well.

As for the parts of Linux, like the scheduling alogrithm, that appear
to be optimized for multi-user time sharing systems, thats flat-out
archaic, in my view. Maybe I'm wrong about this, but when you're the
only person at the console, "fairness" in sheduling is a little less
necessary: you started the damn thing, if you think its taking up
too much time from your sound-card, lower its priority!

> 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:

No indeed!

> 1) Soft real time
> * Typically ms precision timing.
> * No guaranteed deadlines.

I totally don't agree with "no guranteed deadlines", sorry. My last
company made remotely operated undersea vehicles (robots... they had
manipulators and lots of sensors). Its under water, nothing moves very
fast, so 50Hz control frequencies were common. That's 20 ms intervals.
However, *guranteed* response to error conditions and hardware failure was
required, that response had to be sub-second response, not
sub-microsecond, but it *still* had to be guranteed. Its soft realtime, we
didn't need 830 ms (+/- 3.25ms), but the O/S heading to sea, flushing its
disk cache, and blocking our A/D task for 1 1/2 seconds would make the
response noticeably choppy. Not having background data logging impact
control loops was also important, even if the loops were only 50Hz. And
controls engineers always want faster loops, they're never happy.

> 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.
Agreed.

> //David

'ciao
Sam



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [from the cache]
©2003-2011 Jasper Spaans