[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.

    > //David


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:53    [W:0.036 / U:12.504 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site