> On Apr 24, 2023, at 10:52 AM, Sampo Syreeni <[email protected]> wrote: > > It's just easier and mathematically simpler to work in fixpoint.
Huh? No, fixed point is *dramatically* more involved and cumbersome to implement/maintain/debug. Fixed point implementation is an art of its own, often handled by specialists separately from the reference audio algorithm design (which is often double precision float, so that algorithm designers don’t get bogged down in these details). > Earlier you just couldn't have the range for audio work you needed, so there > had to be floats, A/μ-laws, and whatnot. The classic way to get higher resolution fixed point is just to use 32 bit integer types. Or else use dynamic normalization. Also there is no shortage of audio applications where 16 bit resolution is perfectly fine (like CD audio). > (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. Sure, for applications where you control the absolute input and output levels. But that’s only a small minority of audio use cases - in most applications you have no control/visibility over this. > If you know the limits and averages of your input signals, and scale your > sums appropriately. There is, in general, no upper bound on the peak sample value at the output of an LTI filter. Parseval will let you bound the average power, but the crest factor can change by an arbitrarily large factor. It all depends on what signals you play through it, and requires a judgement call to trade off risk of overflow vs underflow vs complexity. A typical fixed point implementation will exhibit nonlinear behavior on both ends, and the art is in limiting this to places where it’s difficult to hear (without blowing up the complexity with high resolution processing). > What's really hard is controlling nonlinearity in your signal processing > algorithm. Yeah this is also difficult, and in practice you often have to rely on libraries with their own ideas about scaling - which you then have to fit your own design to match. > 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. No, it’s the other way around. In fixed point you have to sweat these details at every step of the way. In single precision floating point the error is hundreds of dB down, and you can totally ignore it except for the most numerically sensitive algorithms. > My favourite here is dithering. There's no known closed form solution of how > to do any of it given denormals. Why would you want to dither a floating point signal? > 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. This only applies to the RMS signal power. For saturation you are worrying about peak sample values, which do not admit any general bounds for non-trivial DSP chains. Judicious scaling helps, as does throwing more bits at the problem. But neither of those can totally eliminate the concern about overflow, in principle. The best you can do is to reduce the probability of overflow to some extremely small value. Which is what we do with floating point implementations, which have hundreds of dB of headroom. Ethan D
