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
suggestion?
>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.
Yours,
Juhana
-
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/