[lkml]   [1999]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [alsa-devel] Re: preempting I/O (audio latency + making X more responsive)
    >From:   Benno Senoner <>
    >Mingo demonstrated that it's possible to achieve <4.3ms audio latency on a PII
    >box, on high disk I/O load.
    >( Will post soon nice large GIFs on my page to show the exciting results)

    A source code would be a good one because it saves time even we choose
    a slightly different way to implement it. My plan was to give disk process
    higher priority so that disk process is always suspended by read(), write()
    or by waiting new tasks. What do you think how this differs from your

    >Therefore IMHO the best solution is to have some disk I/O thread which
    >does the I/O for the audio thread using large buffers.

    But loading large buffers blocks the disk usage from other audio streams?
    What about making the large buffers fragmented so that fragments of different
    buffers are interleaved in loading/writing? Using small buffers might
    increase the load of the audio engine and thus fragmented large buffers
    might be a good compromise.

    >With the 2 threads method, the only concern is I/O bandwidth, the latency
    >problems are solved by the large buffers.

    I think that is a bit incorrect. I suspect large buffers blocks the system
    from reading multiple files simultaneously. Latency is increased by
    preloading the audio. Preloading is possible if we have a sequence data or
    an editlist, but if we get a MIDI note, then preloading is not possible
    unless we preload a bit about every possible audiofile the MIDI instrument
    might use. If we allow MIDI instruments to use audiofiles on disk, we should
    use the same latency in any audiofile instruments -- and more, in any
    instrument even if they don't use disk -- so that we don't get jitter between
    instruments. This sequencing latency naturally lessens the performance
    requirements, I guess.

    >You should always use mlockall() for realtime processes.

    I see a slight misunderstanding here and there. I mean, if some non-audio
    software starts to swap or to read disk, then it might block the RT audio
    disk readings/writings. I cannot lock those third party processes but the
    kernel could freeze their disk usage if my RT audio software wants to use
    disk. Prioriticing disk usage and making it preemptive would help. But can
    a DMA transfer be interrupted? Kernel would stop the current disk read (by
    non-RT process) and give the DMA to RT process.

    The disk and the audio RT process would sleep when they wait data and
    at that time, could any other process start some large disk reading.
    That disk reading should be interrupted as soon as possible.

    >It would be nice to hear some comments from the XFree86 people.

    I would like to hear them too, please.



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