Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: David Olofson (david_AT_gardena.net)
Date: Sat Mar 25 2000 - 20:59:40 EET
On Wed, 22 Mar 2000, James McCartney wrote:
> I'd like to see a real world example where you have a signal that is full 24
> bits peak to peak and you can hear some distortion in the low 4 bits.
> Because other than full scale peak to peak signals you will not lose the
> lower bits using 32 bit FP. The additional bits in integer formats is
> usually for the increased dynamic range, not increased SNR.
Uhm, that was not the point here. Someone wanted to make sure that a
full 24 bit integer signal can be passed through the FP system
without being altered.
I wouldn't say the occasional LSB that could be lost in near peak
level samples would make anything but a theoretically measurable
difference. (Not that I can see that it will happen - the mantissa is
actually 25 bits, including the one's bit that's an implied 1 in
non-denormals, and normalizing means only shifting the integer
around.)
> 16 bits is already sufficient if it were just SNR.
No, not unless it's dynamic. Ever heard a CD fade out when playing it
back at above 100 dB peak? Not what I'd like to hear from a hi-fi
system. The only reasons why you can't hear the effect on most
classical recordings is that 1) they're compressed and 2) it's hidden
in the analog noise.
> In any case SC unit generators have a typedef for the sample type which can
> be changed easily and recompile.
Doesn't work. We don't have a standard API if recompiles are
required. Also, the data type needs to be reflected in the version
code to avoid nasty crashes when unintensionally mixing plugins for
different data types.
> But I don't see a real world need for more
> than 32 bit FP. No one is going to hear the low bits in a full scale signal.
No, it's only needed for internal calculations like FFT. (If you've
tried coding a pure 32 bit FFT, you'll see what I mean...) Note that
most FPUs automatically convert to an internal FP format, so as long
as you're not using up all the FP regs, you don't even have to bother
with the types. (That's true for asm at least - I'm not sure you can
rely on compilers not messing this up. Better use doubles for temp
vars.)
> > The 24 bits of dynamics is really needed,
> > as you don't want to get the quantization noise inside the dynamic
> > range of the 20 bit output signal.
>
> You are mixing up terms here. 32 bit FP has 151 bits of dynamic range
> (=log2(FLT_MAX/FLT_EPSILON)), but only 24 bits of signal to noise.
> You don't need as much SNR as you do dynamic range.
This is true when you pass pure audio data around.
But what happens if you add a very high amplitude signal to an audio
signal (to make some other plugin modulate the audio signal for
example), and then filter that signal away. What happens to the
mantissa?
> Most manufacturers of digital
> equipment mix up these terms as well in their published specs. A 24 bit int
> signal has 24 bits of SNR, but the dynamic range depends on the amplitude of
> the signal.
Two different definitions of "dynamic range":
1) The difference between the minimum signal level that can
be registeged, and the clip level.
2) The resolution of a sample at the peak level.
> With FP the dyanamic range doesn't depend on the amplitude for
> any practical purpose.
Depends on what you call a "practical purpose". (See above.)
> > As an example that most of you have probably experienced [...]
>
> This example is all about the limitations of integer formats, not FP.
True; I probably lost track here...
> Not much that a plug in API can do about converter limitations.
No, but it *can* support data formats that let you *process* data
without demolishing it. OTOH, one could avoid that problem by
regarding all "non-standard" (I'd like to see a difinition of
that...) as abuse of the API, rather than taking advantage of the
fact that digital systems *can* handle it, as opposed to analog
systems.
//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 : Sat Mar 25 2000 - 22:16:53 EET