Re: [alsa-devel] Re: preempting I/O (audio latency + making X more responsive)

Benno Senoner (sbenno@gardena.net)
Mon, 23 Aug 1999 18:08:17 +0200

On Sun, 22 Aug 1999, Stephen C. Tweedie wrote:
> Hi,
>
> Benno Senoner writes:
>
> > My plan is to develop a demo app, which opens the soundcard in R/W
> > mode, plays let's say 20-30 .wav files from disk , mix them
> > together , maybe with a little Qt app which allows changing volume
> > + applying a lowpassfilter (parameters adjustable in real-time) of
> > each track, emulates a simple MIDI sampler (just interpolate a .wav
> > file to the frequency according to received note-on events) ,
> > recording the soundcard's input and mix together all sources and
> > write the result to 10 wav files, just to simulate a complex load
> > on a harddisk recording system + software-synth,
>
> Just be absolutely sure that you don't clog the disk IO
> unintentionally with write-behind data. You need to fdatasync() your
> output file regularly to ensure that your latencies aren't going to be
> hurt (badly!) when bdflush decides that it is time to batch your
> updates out to disk.

This is not a problem for me, since using mingo's patches
(with some resceduling hookups at critical parts of the kernel),
I'm now able to run a thread which does no disk I/O, only audio output
and reading from a shared buffer with rock solid latencies <4ms, regardless of
disk I/O load.
Since I use a two threaded model, one doing only disk I/O and writing/reading to
ring buffers running at lower priority, and the audio thread running at
SCHED_FIFO max priority, it works fine.

>
> The way to get best streaming write performance here is to preallocate
> the data in advance (NOT just ftruncate(), which extends the file but
> doesn't allocate disk blocks --- do a real write() of NULLs to the
> file in advance). If you don't do that then you'll end up incurring
> extra disk seeks when you f*sync(), as you need to update lots of
> file metadata as a result of allocating new disk blocks. If you keep
> the fdatasync()s relatively infrequent (say, once every 500--1000ms)
> then the overhead of not preallocating the blocks shouldn't be too bad.

Maybe you meant that fdatasync() will keep latency low in a single threaded
model, but these latencies are way too big , and the only solution is the 2
thread mode.
The problem is that when you do harddisk recording, in some cases,
you don't know in advance the length of the recording, therefore you must write
to the disk dynamically without prealloc or writing NULLs to the file,
even if you have to sacrifice a bit of performance.

PS: Stephen did you look at my other mail about the problem that streaming of
large disks from disk (especially reading) throws all other files/executable out
of the filebuffers and makes the rest of fileops quite slow (when launching an
app several times, the 2nd is slow since the kernel has to re-load from disk),
it makes you feel like running on an unbuffered disk.
I'd suspect that all disks will feel as UNBUFFERED disks, due to streaming
activity.

regards,
Benno.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/