Subject: Re: [linux-audio-dev] cpu/disk tradeoff
From: David Olofson (audiality_AT_swipnet.se)
Date: to loka 14 1999 - 18:51:51 EDT
On Thu, 14 Oct 1999, Benjamin GOLINVAUX wrote:
> and my dog (shame on my dog who still prefers fixed-point dsp).
Your dog is an asm die-hard, then...? :-)
> 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 ?
How would you get it that bad? 70 tracks == 70 files (unless you have
lots of very small clips that are spread all over the disk...), and
that's around 20-30 seeks/s with 3 s of buffering, for example.
Big advantage: You don't move data at all, and hence, edit operations
don't stress the disk while playing back.
One solution to the "many small clips" problem would be to have a
background optimizer daemon that creates new iles with the audio
data of these clips in sequential order. However, I doubt it'll be
much point, as small clips that are moved around are usually either
1) rythm tracks where the user (or some automatic tool)
manipulated the timing slightly, or
2) rythm loops, where the clips are actually used as if
the HDR was a sampler. Most of those clips will be
reused many times in the song.
And, 1) won't make much of a difference, as the clips are just slided
a little, as opposed to heavily shuffeled around, which means that
the read buffering will smooth it to a sequential stream, just like a
single, long clip. 2) means that the total size of the clips doesn't
justify them being streamed from disk - a reasonably smart cache in
the streamer daemon should take care of this.
> 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.
The average hard disks is still pretty slow compared to the CPU, so
if you don't need the full float resolution, there's not much point
in doubling the HD load. However, 16 bits for recording isn't all
that much, so 16 bit files only is not the way to go. I've seen
applications that use 24 bits/sample in files...
> 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 ?
Nothing that works is too weird for a rather simple but important
task as this, but check out the FP instruction set of the CPU first.
A decent CPU *should* be able to do this efficiently without "dirty"
tricks. The real world frequently turns out to be just as bad as you
expected, though...
> 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 ?
Editing while playing back, no waiting for "commit", no waiting for
undo...
> 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.
That certainly makes more sense than going short int only, especially
considering the performance of HDs these days, 20 and 24 bit sound
cards, and Benno's multitrack streaming results.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST