> On 04/08/2023 5:31 PM EDT Sampo Syreeni <[email protected]> wrote: > > > On 2023-03-27, robert bristow-johnson wrote: > > > I think denorms are a good idea. They should be handled routinely by > > now. > > I do too. However I think in the DSP circuit they are also a kind of > stopgap. If you want to do floats at all, you ought to be able to known > in which regime of semi-logarithmic processing you'll be working at. And > why you do so.
I just want to implement and encode an algorithm as close as possible to the textbook equations as possible, without worrying about quantization, clipping, the "cosine problem", and other nasty little details we have had to worry about a quarter century ago. > The thing in audio signal processing in the 64-bit age of now is that > you *can* have the linear range for anything and everything, without > packing it into a float. Well, when a sample is imported from an ADC or a file as an integer, *once* *there*, we convert to float. > Of any width. You would have had it even in > 32-bit fixpoint, and even in 24-bit, if you minded your gain structure. And that's what the promise is of 64-bit floats. So we never have to worry about the gain structure until the samples are converted to integer so to be outputted to a DAC or written to a red-book CD. Or, converted to mp3 or something like that. > There's absolutely *no* necessity to go into floats, their nonlinearity, > and the idea of denormalised numbers, at such word widths. It's not a necessity like it was with the DSP56000. It's taking advantage of the feature that you have a 64-bit CPU, 64 bit wide data bus, dozens or hundreds of gigabytes of 64 bit wide memory. Now, how cheap is that environment now? If you have that, then why not use it? The only why not that I can think of is some fucking denorm causing an exception and putting in a glitch in your output. That's why we had to set FTZ and DAZ both to 1 in the past. But we shouldn't have to do that now. And "what shouldn't be" and "what is" is sometimes, unfortunately, not the same. > > And in fact most well thought-out numerical algorithms ever do, or > should go. If you go through the numerical analysis of most proper > filter algorithms in existence, they don't hit the denormalisation > bound. A simple IIR will hit denorms when dead silence is going in after some non-silence excited the states of the filter to non-zero values. > Or if they do, they actually hit a nasty, low level, knee of > nonlinearity. That's right and I don't want that to cause a fucking exception. But I wanna keep having the utility of denorms. > They'd do better if they just went with well-calibrated > 24-32 bit fixpoint. Listen, people here that know me from the 1990s, know that I was a staunch fix-point advocate. The company I was working for (Wave Mechanics, later renamed SoundToys) did an early SHArC-based product for another company called Zaxcom. It was the beginning of doing actual floating-point processing in the end product (not a MATLAB experiment). And there was trouble. 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. > Not to mention 64-bit stuff. Even in floats. Because the IEEE floating > point standard actually allows for precisely 24 bits for the significand > at 32 bits total, which is more than proof for linear audio signal > processing without utilizing the exponent at all, and then the 64-bit > version gives you 56 bits of significand, which only local astronomical > simulations really require; only distant ones really then require the > exponent. At all. I will never expect audio calculations to go astronomic in scale. 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? 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. -- r b-j . _ . _ . _ . _ [email protected] "Imagination is more important than knowledge." . . .
