lkml.org 
[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)
    Date
    From
    >> I consider the idea of a single-processor system replacing, say, a
    >> dedicated Lexicon rack unit or a Quadraverb 20, to be pretty
    >> silly.
    >
    >Why, when it's a "simple" matter of fixing the real time scheduling? Off
    >course, cache misses and similar problems might suggest that latencies
    >below 3 ms shouldn't be used for efficiency reasons. That's a user level
    >choice, though: A little more CPU power, or extremely low latency.

    a "real" FX processor can do real-time flanging with a 0.2ms
    delay. the idea that linux (or beos) for that matter can step into
    this kind of role is absurd, or close to it.

    >> >Yep, I know, and fixing that might be enough. However, is that enough to
    >> >guarantee that a real time task will get control within any defined
    >> >time? I want figures. Hard, real, reliable figures.
    >>
    >> it depends on what you mean by "any defined time". if a SCHED_FIFO
    >> task is *not* running, and an interrupt occurs, then my sense of the
    >> kernel code is that you are *guaranteed* that it will be scheduled to
    >> run immediately. if the timer interrupts aren't frequent enough for
    >> you, you need some other source of interrupts. for these purposes,
    >> those of the soundcard itself work pretty well.
    >
    >For the processing thread, it's a lot less than 5 ms. A lot less,
    >because signal processing is CPU intensive, and I want plug-ins to be
    >able to utilize more than a fraction of the available CPU power. There's
    >hardly no room for cathing up after a stall under heavy load, so this is
    >very important.

    i think (but don't know) that you're wrong. quasimodo does a lot
    (arguably all) of what you are talking about, and it works the way i
    describe. if you are in a tight loop reading from the ADC, processing,
    and then writing to the DAC, the timing i describe is exactly what you
    want.

    >"Average latency" and "maximum latency" are two very different things.

    no - latency and jitter are two different things. what we have a
    problem with is jitter, not latency. the difference is subtle but its
    important because it affects how you think about solving it.

    >> >What is an audio application?
    >>
    >> Take a look at http://www.op.net/~pbd/quasimodo/ for my answer to that
    >> question.
    >
    >That's a pretty nice answer! :-) That code will be nice reading, if you
    >don't mind. ;-)

    be sure to get it from CVS. i'm spending a lot of time right now
    working on tightening down the screws on the real-time FX processing
    loop.

    --p

    -
    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    [W:4.758 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site