lkml.org 
[lkml]   [1999]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [alsa-devel] Re: preempting I/O (audio latency + making X more responsive)
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.

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.

--Stephen

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.227 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site