Subject: [linux-audio-dev] multiple files/single files for HDR: my verdict
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe loka 15 1999 - 12:44:36 EDT
i just noticed a nice trick that arises from use multiple files for
multitrack HDR.
suppose you're currently only have a single input channel. ideally, to
minimize load on the disk subsystem and scheduling jitter, you'd like
to to only write a single output channel. if you interleave the
channel data, you can't do this, but if you use one fd per track you
can.
but the trick is even cooler (or it feels that way right now). as you
may know, lseek (fd, some-value-beyond-size-of-file, SEEK_SET) will
result in a zero-filled block if the file is subsequently written to
after the seek.
so ... when you add a new input channel/punch in a track, if you keep
track of where the one that is already running is writing to, you can
just seek there, and start writing. instant sync. this makes
punch-in/punch-out very efficient (though you may have to extend the
track files on closing if you punched-out and never punched-in again,
just to make sure they are all the same length. lseek() is your friend
here too.
this means that you can fire up "hdr", for example, with the potential
to record as many tracks as your system can handle, but only actually
use the bandwidth necessary for the number of tracks currently being
sent to disk.
perhaps this is all totally obvious to you, but it wasn't to me, and
it took me a little while to get it to work with multiple threads. but
now it does, and it seems very nice.
--p
ps. simple demo:
tapedevice = new TapeDevice (48); /* track maximum */
tapedevice->load_tape ("my-session");
tapedevice->run ();
/* at this point a writer thread is sleeping, waiting for work to
do. Later, the main thread does:
*/
tapedevice->write (mybuffer, nframes, track_number, Sound::float32);
/* in a tightly-synced program like HDR, where all the input/output
channels are processed in a loop, we call ...
*/
tapedevice->flush ()
/* ... for each iteration around the main loop. This will wake up
the writer thread if 1 or more tracks have more than
frame_write_threshold frames pending.
Then we do output to our soundcard(s), which will put us to
sleep for a little bit, and let the tape writer thread run (on
a UP system, anyway).
Alternatively, the device can be set to flush automatically
every time the amount of pending frames exceeds a certain
threshold. This would be more appropriate for single threaded
programs and/or those without a tight "DSP-like" central loop.
*/
Coming soon to a tarfile near you.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST