13 Nov
2003
13 Nov
'03
6:57 a.m.
Paul Davis:
Perhaps it would help programs that does everything inside one process,
like snd.
--
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.
13 Nov
13 Nov
8:41 a.m.
New subject: [linux-audio-dev] Fwd: [[NO] PATCH] cfq + io priorities
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.
noon
New subject: [linux-audio-dev] Fwd: [[NO] PATCH] cfq + io priorities
Paul Davis wrote:
I agree with Paul here: a two threaded model with relatively large
buffers will be always needed,
perhaps the real time disk scheduler can help to shorten these buffers.
For example in LinuxSampler we preload a chunk of each sample and this
part must be big enough
to overcome disk latency when loading the rest from disk.
Perhaps this disk scheduler can help to reduce those buffers a bit but I
don't think you will be able
to reduce them significantly.
A disk is and will remain a slow beast when it comes to seek times,
especially on a multi tasking system.
Benno
http://www.linuxsampler.org
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 :)
7476
days inactive
7476
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Benno Senoner -
Kjetil Svalastog Matheussen -
Paul Davis