Subject: [linux-audio-dev] cpu/disk tradeoff
From: Benjamin GOLINVAUX (golinvaux_AT_benjamin.net)
Date: to loka 14 1999 - 16:09:17 EDT
Hi !
I'm trying to devise a good sample edition and streaming method,
and I've already been kindly advised by users on this list to use a
different file per processed part of my audio files, regarding non-
destructive editing.
However, there are two additional decisions that I don't wanna take
before having explained them to a broader audience than just me
and my dog (shame on my dog who still prefers fixed-point dsp).
** 1 ** Regarding edit lists issues, I saw two solutions : keep a list of
undo stack events, where each event would be desribing a past state
or the present state of audio file. This event would be a list of file
entries,
along with offsets in this file and duration. This list would then be used
to playback the sample. I wonder if it wouldn' be faster to always compute
a whole file, and save the modified bit to a temporary file. This way, the
undo stack would give a way to reconstruct the file incrementally. The
point here is to minimize disk seek times by always having the disk read
thread read a single file... Imagine I have 70 tracks playing together,
would I want the playback to constantly switch between 700 files ? I don't
think so... When the user clicks the undo button, another temp file is
created, filled by the undo thread (which is separated from the playback
thread) and a semaphore is released when the playback thread is allowed to
switch to this new file (perhaps shorter or longer than the original)... As
I'm
explaining it, it *seems* better... But David obviously choose to describe a
method like the first one.
** 2 ** Another issue... Let's assume my output buffer is floating point,
should I convert EVERY working file to floating point BEFORE ever
processing it (and save it to a temp file) in order to later mix the file
data
within the output buffer without run-time conversion, or should I perform
run-time conversion... I can't clearly decide if doubling (16bit -> 32bit)
the
disk load and thus reducing the number of available tracks is better or worse
than diminishing DSP performance by having each read buffer converted to
float, sample by sample. RELATED : I thought of a way to store 16bit
"numbers" in a special format where the data could bne OR'ed with an
exponent mask to directly produce floating point values without calling the
float->int asm opcodes (assuming x86) ? Is it too weird ?
If it were up to me, I'd choose to read a single file per clip, and store non
-
destructive edit lists in separate files read only during undo operation...
Playback must be fast... Undo, we don't care... So why do mjor packages
seem to use the many-files method ? Have I been misinformed ?
Regarding float/int, I'd go float, because I know I'll try to push the dsp
tests to the max, while I don't think I'll reach the maximum number of
tracks anytime soon.
Any comments ?
Benjamin GOLINVAUX
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST