Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: David Olofson (david_AT_gardena.net)
Date: ma maalis 06 2000 - 17:02:09 EST
On Mon, 06 Mar 2000, Bill Gribble wrote:
> > And even 16 bit integer signal paths with 32 bit integer processing
> > is good enough for non-pro signal processing, such as multimedia
> > systems, games, arcade game machines and the like.
>
> I think this integer = non-pro, float = pro dichotomy is bogus.
Ok, but if we drop that, we have to drop the Intel platform as well,
as it's int/float conversion sucks, and most programmers don't feel
like fiddling with fixpoint arithmetics.
> All existing digital audio wire formats (s/pdif, aes/ebu, TDIF, ADAT,
> others?) are based on integer sample values.
Yes. Little or no processing is done on that level.
> All digital recording
> media are based on integer sample values.
No. Some modern HDR systems, and computer based systems store audio
data in 32 bit fp format on disk.
> I see no reason why
> floating point values are more useful for pro audio applications, and
> a lot of reasons why integer representations are better.
1) Far superior dynamic range - no need to normalize data.
2) No need for using inline asm code to take advantage of
32*32=>64 and 64/32=>32 operations.
> For a given
> number of bits in your value, a floating-point representation wastes
> much of your available information in large and small values that are
> far, far beyond the limits of your ultimate destination and will never
> be used in real applications.
That is only true as long as thu integer is always using all bits, ie
0 through -6 dB. fp numbers have dynamic resolution, which fits audio
signals perfectly.
> The phenomenon of linear quantization noise has well-understood
> remedies in domains where possible values are evenly-spaced in the
> domain of the representation (i.e. integer sample values); I don't
> know of any way of meaningfully dithering or otherwise changing the
> word-length of floating point values while still doing the right thing
> WRT quantization noise.
Just do plain truncation of the mantissa after shifting it to the
right position, according to the exponent. That leaves you where you
are with integers in the first place.
Floats only drop bits when your values have a greater number of
significant bits than the size of the mantissa, of when you exceed
the range of the exponent (which is many orders of magnitude beyond
the dynamic range of an integer of any sane size!)
> Floating point makes things easier for the *programmer* (fixed-point
> arithmetic is fiendishly hard to code up correctly). Given 32 bits to
> work with, and inputs and outputs that will be within a 24-bit range
> for the foreseeable future, I'd much rather have a fixed-point
> representation than floating point.
Ok, so how do you solve the problem with lost bits due to low signal
levels between plugins? Cool. The SNR problem of analog systems
simulated with digital truncation! ;-)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST