On 11/23/2018 09:18 AM, Gordonjcp wrote:
On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote:
On 11/23/2018 01:00 PM, Will Godfrey wrote:
[...]
Thanks for going into this in such detail Robin. I never realised fp stuff
could be *quite* so, umm, approximate!
Depending on context and the maths, the difference may not matter at
all, or may be off completely..
Surely the answer is just to use 16-bit ints for everything, then...?
I've said before: Bankers forbid fp and use BCD math,
otherwise pennies go missing which accumulate into dollars.
Unless Will's requirement is scientific or astronomical,
yet still requires a fairly wide range, I suggest 128-bit int math.
It may not be useful with plugin or jack audio paths, which are
always fp, but for other things like time it really helps.
Until several months ago MusE used fp to represent time, such as
wall-clock time and jack time etc. It caused many timing problems.
So I ripped up all of that and used 128-bit int math instead.
You just have to carefully determine your required range and
change the units that it represents. In MusE's case, the time
value now represents 128-bit int nanoseconds instead of fp seconds.
128-bit math is not supported fully yet on all platforms
especially 32-bit platforms. So I used a third-party library
'libdivide' which handles the cross-platform stuff.
I made a convenient routine which does A * B / C in 128-bit math
since that is by far the most common general usage in our app.
Tim.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
