Subject: Re: [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: Fri Sep 29 2000 - 03:08:13 EEST
On Fri, 29 Sep 2000, Benno Senoner wrote:
>> 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.
Uhm, those stalls are just the thing I'm after here. From apps point of
view, they do appear to be caused by read()/write(), although the real
cause is in the lowlevel filesystem buffers.
> 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).
Yup, this is definitely a very important point (=affects app design
in a major way). I'm usually not very enthusiastic about performance
optimizations. For instance, trying to get around problems caused by
kernel task scheduling delays, is of low priority to me, because it's
something that can be solved on the kernel level (ll-patches). But
this disk i/o latency seems to be a more interesting 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
> 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
Ok, this is exactly what I wanted to hear. :) Oh well, I guess it's time
to replace by fancy mmap-disk butler with a more straigthforward
system.
> 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
I've already implemented this (although so far only for file inputs), but
I did it on the file i/o level. This limits the use of doublebuffering to
file formats, which are handled internally (wav, raw, cdr). Formats using
external libraries/sw (mp3, libaudiofile, etc) don't go through the
doublebuffered layer.
Extending the above system to affect all non-realtime audio object types,
shouldn't be too difficult, but it will require _lots_ of work. That's why
I want to be 99,9% certain, that the buffering system really works, and is
something that doesn't need to be rewritten every now and then.
And of course, I need to make sure, that all extra buffering can be
optionally turned off. When all inputs and outputs are non-realtime
objects, you want to minimize the input->process->output execution path,
and use of resources (multiple threads and big memory buffers are not
needed in these cases).
> 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)
Ok, I'll try these.
> 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
Actually this is not that bad when there are only realtime objects
involved. For instance, you can do realtime effect processing quite
nicely using one soundcard for recording and another one for playback.
Not that many musicians can hear the sample drift. :) But of course, if
you add files (or otherwise need to sync the soundcard signals to other
sources), you are in trouble.
> to implement some resampling or sample skipping/duplication,
> in order to keep the stuff in sync.
[...]
> Kai, how do you solve this in eca ?
Well, I don't... I usually give people a link to Audio-Quality-HOWTO,
which covers this problem quite nicely. :) I'm not sure if it's even worth
the effort to get around this limitation. Even if you could solve this, it
would not look nice, and wouldn't work in all situations. If you could
monitor the exact hw-position of the audio device, and measure how long it
takes to process a certain amount of samples, it'd still be hard to come
up with a efficient way of doing this.
-- . 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 : Fri Sep 29 2000 - 09:37:19 EEST