Teensy Audio Library question

[dimitre]

This is for @Paul
I remember the library is written using integers and I thought it was an optimization for Teensy LC or something like this, but I'm now stumbling in something much deeper. I'm trying to skip floating point arithmetic for a personal project and representing pure geometry operations and I suspect it has a lot less errors.
Does it have anything related to your Teensy Audio Library design?

 

[tomas]

As I understand it, the audio library uses DSP instructions https://developer.arm.com/documenta...t-summary/Table-of-processor-DSP-instructions

for speed, not for accuracy. Some of the instructions operate on 16 bit data to allow 2 arithmetic operations per cycle.

Of course Paul may have much better explanation

 

[MarkT]

For speed and for their saturating arithmetic...

 

[PaulStoffregen]

Does it have anything related to your Teensy Audio Library design?

To specifically answer whether it is related to the audio library, I would need to know what "it" is. But I have pretty much no idea. All I know is the words you gave, "skip floating point arithmetic for a personal project and representing pure geometry operations".

The audio library began in the days of Teensy 3.0 and much of it was written as Teensy 3.1 and later Teensy 3.2 were the main version most people used. None of those had a FPU. They were also much slower than today's Teensy 4.0 & Teensy 4.1 in terms of CPU speed and other important factors like memory bandwidth. I put a lot of work into optimizations built around the limitations of the hardware we had in 2014.

Whether that sort of work makes sense today for your pure geometry operations, I just don't know. But if I were to make a blind guess, I'd go with "probably not".

Current Teensy has a very capable CPU with fast FPU and tightly coupled memory. The best case scenario for integer only algorithms usually isn't much faster than using the FPU. But achieving that speed can take a lot of work! Because the raw speed of the FPU for 32 bit float is about the same as integer math, you can easily end up with slower code using integers if you get into complexities like if-else checks on numerical ranges than wouldn't have been needed with floats.

Whether any of this is relevant to your project, I don't know. But hopefully it helps.

 

[dimitre]

Thanks all for the detailed explanations.
Just for clarification I'm calculating some series of harmonic ratios and using std::ratio (integer arithmetic) to keep everything tidy until floating point is needed. usually just for display on screen, so waveforms are a little bit more correct.

 

[Mcu32]

Why do you need float for a display? Assuming it is an HDMI 8K display, 16 bits are still sufficient to exceed the resolution.

 

[dimitre]

ow sorry I think I confused you greatly.
I mean floats only used to display to user. in a UI or screen or printed, whatever. but internally everything is preserved as ratios