Re: [linux-audio-dev] cpu/disk tradeoff

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] cpu/disk tradeoff
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to loka   14 1999 - 21:04:44 EDT


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

my new program hdr works entirely with sample_t's, which are currently
typedef'ed to be floats. it only deals with 16 bit data at its inputs
and outputs - every where else in the data path, and in its own disk
files that it writes as a sort of equivalent of a tape, we use floats.

16 bit is completely inadequate for professsional audio intermediate
storage and manipulation. Its adequate for the final result, IMHO, but
thats not the same thing at all, as many people have pointed out.

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

why would you want to do this ? why not just use float all the way
until you ship the data to a 16-bit requiring destination (e.g. most
soundcards) ?


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST