13 Nov
2003
13 Nov
'03
9:41 a.m.
Paul Davis:
Perhaps it would help programs that does everything inside one process,
like snd.
not very likely. the problem with disk i/o is that it actually takes a
long time to read the data even without OS scheduling delays. you can
see this in snd relatively easily: keep adding more channels to a
soundfile, and snd has a harder and harder time keeping up. after
about 12 channels (YMMV), snd can't keep up at all. its not that the
streaming rate from the hardware isn't good enough, its that the seek
time makes it effectively much lower.
realtime i/o priority will help a bit, but it won't change the basic
fact that you cannot do disk i/o within a realtime audio thread (unless
you want it not to work :)
I guess
this will be of interest to some of you...
An even newer version has shown up on linux-kernel.
its not clear how useful this really is. we know that the disk i/o
system can't keep up with realtime needs by definition - there has to
be a significant buffer between the disk and the RT audio thread. i'd
be suprised if it really helps any actual apps, because they've
already got this buffer in place, and the buffer hides the lack of
dedicated resource allocation on the part of the kernel.