Subject: [linux-audio-dev] disk i/o latency, mmap and more (was: Re: Reverbs... and the usual whinings)
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Thu Sep 28 2000 - 22:20:12 EEST
On Thu, 28 Sep 2000, Benno Senoner wrote:
>> Hmm, is the disk i/o latency (over 1sec stalls possible) something of an
>> accepted compromise (from disk-i/o design perspective), or is it something
>> you should expect to vary (possibly a lot) from impl. to impl.?
> do you mean varies in function of application implementation or kernel
> implementation ?
I meant the lowlevel (kernel) implementation, ie. varience in
read()/write() execution time.
>> How do 2.2.x and 2.4.x kernels compare here?
> I think max stalls of 0.5 sec is quite realistic and would mean halving
> (or reducing even more) the disk buffers.
Ok, but this is definitely something that will not go away (ie. we will
always need to do doublebuffering for disk i/o in audio apps)...?
Btw; what happened to the 'sched_fifo_thread+mlock()+mmap()' approach that
was discussed on this list about a year ago? I remember many of us were
behind it, and even implemented it (including myself), and got fairly good
results. Then at one point, I read a linux-kernel message from Linus,
which critized the use of mmap() for streaming purposes. Ever since that
msg, things have been much more quiet around this issue.
I've spent a few days going throuh EVO and ardour code... EVO seems to
implement both (read/write_with_io and read/write_with_mmap). Ardour
then again, seems to use mmap() only for soundcard i/o.
Any new information about how these techniques compare?
...
Basicly I'm still trying to figure out how to improve ecasound's i/o
subsystem. I've tried out many different approaches, but all have had
problems. The fundamental one is, that unlike with ardour and EVO,
ecasound isn't aimed at certain type of use. The basic design is
"x inputs" --(mix)-> "y chains" --(process and mix)-> "z outputs"
In ardour's case, you know that x = y, and that all inputs are realtime
inputs, and that all outputs are non-realtime. In EVO, you know that x >
z, and that inputs are non-realtime (files) and outputs are realtime
(soundcard). With ecasound, all combinations are possible. Even worse,
some inputs/outputs are a cross between non-realtime and realtime (pipes
for instance). So I'm trying to find out a good combination of
optimizations (buffering, threads (smp), priorities). Disk i/o latency
seems to be a solid starting point.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
This archive was generated by hypermail 2b28 : Thu Sep 28 2000 - 23:09:27 EEST