On 2023-04-08, robert bristow-johnson wrote:
Listen, people here that know me from the 1990s, know that I was a
staunch fix-point advocate.
And people don't know me. For a reason: I'm not a practitioner, but a
theoretical amateur in the field. You have every reason to chastise me.
However, about floats, fixpoint and denormalisation...
It's just easier and mathematically simpler to work in fixpoint. Earlier
you just couldn't have the range for audio work you needed, so there had
to be floats, A/μ-laws, and whatnot. But now you don't need them.
Definitely you don't need them in discussing 64-bit arithmetic; as I
said, even usual 32-bit C-float lets you have a linear range of 24 bits,
signed, which is more than enough.
I do understand where floats and denormals come from. They're half about
numerical analysis, and half about software development ease. If you
want to deal with quantities which range wildly over orders of
magnitude, and their inexatitude is relative, not absolute, you'll want
floats. There's really no substitute for floats there. Then if you want
your numerical algorithm to not underflow, in many cases you'd want your
floats to denormalise — which is to say, suddenly behave linearly,
unlike floats as an exponential representation do, and like fixpoint
does.
Since we're talking on a sound-minded group, I perhaps should remind you
of "the gain structure". How analogue studios controlled their noise.
I believe the choice of digital gauge is very much the same as that one.
If you do it wrong, on the analogue side you'll be left with unbearable
noise. On the digital side, you'll be left with digital rounding noise.
But if you control your gain structure right, especially within nowadays
rather wide 24-bit architecture, you really don't even have to think
about it too much. It mostly just works out.
(I'd actually say, calibrate your studio absolutely, like them movie
people do. Done so, a 24-bit linear stream goes below perceptual
threholds when quietest, and exceeds the threshold of pain at max. So it
linearly covers the whole range, and the representaation can be worked
with as wholly linear — except that nobody currently does so. Not even
the movie people; even they mix in relative amplitude and only then set
the final absolute calibration. I think that's thoroughly stupid; the
one little wing of our important audio work which actually *has* a set
amplitude reference, chooses not to utilize it.)
If given an assignment of developing an audio processing system using
fixed-point math, I will not shrink away from the challenge, but
**if** the project is "Hey we got this 64-bit ARM with FPU in it and
gobs of memory, I don't want my code to be checking for saturation and
"minding the gain structure". Fuck no.
You don't have to mind saturation if your gain structure is well thought
out. If you know the limits and averages of your input signals, and
scale your sums appropriately. It's not even hard. Even for me, as a
rank amateur.
What's really hard is controlling nonlinearity in your signal processing
algorithm. What's doubly hard is controlling the semi-logarithmic
tendency floats obviously do, *and* at the same time ne linear ramp
denormals produce. Floats and denormals *do* make it easier for the
average chump to churn out his average numerical codes, but once we go
into numerical analysis, signal processing, for real, as this list is
ostensibly about, that mix of linear and semi-logarithmic is a horror.
You don't want to deal with it; if you don't think it's a horror, then
you haven't tried to deal with to begin with.
My favourite here is dithering. There's no known closed form solution of
how to do any of it given denormals. You can do some of it using floats,
but only after approximating them via a true exponential. Denormals,
they are impossible to analyze together with floats; you can't easily do
mathematics in the linear and multiplicative domains, at the same time.
Especially when you cut off the regime arbirarily, at your lowest float
bit depth; that's yet another arbitrary nonlinearity to your analysis,
right there.
But, if my tool is a 64-bit processor that can do 64x64 to 64-bit
result in the same nanosecond instruction cycle as anything else (like
32-bit fixed-point processing), why would I toss that headroom and
legroom away?
But it can't, basically because of carry propagation in digital
circuitry. It is impossible to do sums or products in O(1) circuit
width. This means that 32-bit arithmetic will always in the end be more
efficient than its 64-bit bigger brother. That being when it applies; if
you really need 64 bits, then the hardware often helps you. But if the
underlying algorithm can be parallelized to two 32-bit ALU's, the
narrower bitwidth will necessarily win out.
It's only when a **final** sample value is getting output, that I
should need to worry about gain, saturation, quantization, and
noise-shaping. I shouldn't have to worry about it anywhere else.
Not if I'm using a 64-bit ARM.
I beg to differ. My ideal is that whatever you bring into your audio
processing chain, is absolutely referenced. It has an absolute decibel
level attached to it. Like them movie people attempt to do it.
If you work like that, and your gain structure follows, there's no
saturation or quantization or anything like that, anywhere, ever. You
can and *will* work within the 24-bit linear range of even a 32-bit
float, because 1) going lower than 1-bit would be unhearable, and 2)
going to the full 24 bits would literally split your ears. Then between
those wide limits, you have full linearity, which helps you produce
better and more stable algorithms.
--
Sampo Syreeni, aka decoy - [email protected], https://urldefense.proofpoint.com/v2/url?u=http-3A__decoy.iki.fi_front&d=DwIDaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TRvFbpof3kTa2q5hdjI2hccynPix7hNL2n0I6DmlDy0&m=vtOGzNBjAn2ZUHBbbrTjtPH5lT5cspQKezjas3QGq6riiKpwBIILlEmP4abhgKuV&s=EYOxKpb4AY3RHbbrEfII0e9ytjZ1iFe_oZdrui2uTYM&e=
+358-40-3751464, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
