[lkml]   [1999]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [alsa-devel] Re: real-time threaded IO with low latency (audio)
    >Yes, I've seen the KURT site, but not looked much closer at it.

    You should :)

    >Perhaps I should have mentioned Firm Real Time as a third kind. (It's
    >more or less what I sugested for multimedia later on in the original
    >post. However, I really don't like the normal mode/real time mode
    >switching idea...) But as I was more focused on the issue that makes all
    >the difference to some applications; guaranteed maximum latency;

    To rehash a point made on alsa-devel recently:

    Realtime software synths and FX processors don't require low latency,
    although its certainly useful. Linux (like most other reasonable
    operating systems) doesn't get in the way of low latency. You can set
    the fragment size as low as the soundcard h/w will allow, and you'll
    get the latency you asked for.

    What they require is guaranteed maximum *jitter*. This is where the
    problem comes in. I don't believe that RTLinux is the required answer
    here. These applications are not hard real time in the sense that
    RTLinux has been written to support. All they ask is that the
    operating system never deny them resources if they want to use them
    and such use doesn't interfere with or require the cooperation of any
    other subsystem and/or process. That means "CPU hungry", not
    "absolutely constrained by timing issues".

    Linux doesn't do this right now. If someone else is using a "key"
    piece of the kernel, then nobody else may proceed in spite of the fact
    that proceeding would not utilize or corrupt any of the resources used
    by the current lock holder. That is, lock granularity is not only too
    large, but crosses distinct protection domains which should be

    The "simple" change of explicitly recognizing the existence of
    distinct I/O subsystems would provide almost everything that a "low
    latency (audio)" application requires; it might even provide it
    all. Allowing I/O via hardware unrelated to the disk subsystem to
    proceed unhindered by disk I/O is good sense for all kinds of reasons,
    and would move Linux into the BeOS arena in one step.

    KURT would be nice for audio (and possibly MIDI) sequencing, but not
    necessary for the above solution to offer all of its own
    benefits. What exactly are Linus' objections to the KURT patches ?

    Aureality sounds interesting, but as est observed, unlikely to offer
    an environment conducive to interesting audio application
    development. SCHED_FIFO+I/O subsystems seems like a much more
    interesting approach to me.


    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.020 / U:17.808 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site