Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Sun, 22 Aug 1999 12:36:49 +0100 (BST) | Subject | Re: [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/
| |