Subject: Re: [linux-audio-dev] disk i/o latency, mmap and more (was: Re: Reverbs... and the usual whinings)
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Sep 29 2000 - 03:13:40 EEST
On Thu, 28 Sep 2000, Kai Vehmanen wrote:
> 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.
that's a negligible time compared to the stalls I'm talking about.
The syscall overhead in the microsecond range, while the stalls
an app can experience during heavy file IO (mainly writing), is
in the range of 1-2sec, which means 100k times higher.
>
> >> 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)...?
Of course, and you have to do this on every OS , including SGI IRIX and
BeOS.
The key lies in the buffersize. On BeOS and SGI you can use much smaller
streaming buffers , which greatly decreases memory consumption of
HDR apps. (eg. let's assume we need 256KB x 100 tracks = 26MB of RAM
on Linux to get reliable streaming. On BeOs the same can probably be done
by using only 64KB per track, thus saving 20MB of "wasted" memory).
>
> 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?
I can only speak for EVO:
I use plain read() / write() because it's faster than mmap.
I began my work with mmap() (and the routine is still here in the
streambuffer code, but it's unused) but measurements showed that
read/write was faster, and this is as Linus said, because of the fact
that mmap has to keep track of and traverse large page tables
which can hurt quite a bit when dealing with huge files.
When dealing with audio IO, using mmap over write() is to gain
a bit in terms of overhead reduction, but this gets noticeable only
when dealing with very low buffersizes, and even here you save
only 1-2% of CPU max.
From th description you gave below , it's quite a complicated case,
and since you have to deal with pipes and files, buffering mandatory.
I suggest you to do all file I/O in one single thread if possible , because
this improves performance. (but be sure to not read too much data
with one single IO call or so that you do not need too big buffers)
(if you use a bufsize of K, do no read more than K/2 or K/4)
and the situation becomes even more painful if
"x inputs" or "z outputs" are different soundcards:
if one card's samplingrate drifts even minimally, you will have
to implement some resampling or sample skipping/duplication,
in order to keep the stuff in sync.
(remember the old soundcard sync discussions on this list ?
basically no one has posted working synching code yet)
Kai, how do you solve this in eca ?
cheers,
Benno.
>
> ...
> S
> 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.
This archive was generated by hypermail 2b28 : Fri Sep 29 2000 - 02:01:44 EEST