Re: [LAD] Is -ffast-math safe for audio?
Am 22.11.18 um 22:41 schrieb Fons Adriaensen: On Thu, Nov 22, 2018 at 09:27:58PM +0100, Hermann Meyer wrote: In guitarix nearly all DSP is generated by FAUST. That doesn't make any difference for numerical stability. This is a property of an algorithm, not of the language. Ciao, Just as a side note, we've no problem in guitarix when we use float instead of double. I've done so for some ARM ports. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
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
Re: [LAD] Is -ffast-math safe for audio?
In Fri, 23 Nov 2018 17:56:38 + Gordonjcp wrote: > On Fri, Nov 23, 2018 at 10:33:24PM +0500, Nikita Zlobin wrote: > > In Fri, 23 Nov 2018 14:18:01 + > > 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...? > > > > Let me note - it would be at least 32-bit int, since in 32bit float > > significand is 23bit. > > We don't need that much precision, we only have 10-bit ears. > Oh... when you wrote "for everything" - i thought, it includes processing too, not just listening. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
On Fri, Nov 23, 2018 at 10:33:24PM +0500, Nikita Zlobin wrote: > In Fri, 23 Nov 2018 14:18:01 + > 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...? > > > > Let me note - it would be at least 32-bit int, since in 32bit float > significand is 23bit. We don't need that much precision, we only have 10-bit ears. -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
It's probably gonna be silly question, but after short analysis i don't
see, what could be broken in this demo snippet, when float is standard
single-precision 32bit type.
I omit first case, as optimizing compiler could just optimize it to
just =1; though it could do it in second case too... (as assumed, i did
not try to compile it yet).
But even without underhood tricks - 32bit float has 23/24bit for
significand, thus
In Fri, 23 Nov 2018 14:09:02 +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..
>
> float a = (1 + 1e20) - 1e20;
> float b = 1 + 1e20; b -= 1e20;
> printf ("%f %f\n", a, b);
>
> Any guesses what this code prints without compiling it? :)
>
> > I was using O3. Following on from this I found that if I removed
> > either O3 or ffast-math the problem disappeared.
>
> OK, so SSE/AVX/compiler-intrinsics are the issue at hand.
>
> > It's quite possible that I'm over-thinking this as there are
> > actually only a few iterations before the initial figures are
> > re-calculated, but I don't like mysteries :(
> >
>
> You could also disable this for a specific function only
>
> __attribute__((optimize("-fno-fast-math")))
> void different_mysteries_here (float val)
> {
> ...
> }
>
> ciao,
> robin
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
In Fri, 23 Nov 2018 14:18:01 + 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...? > Let me note - it would be at least 32-bit int, since in 32bit float significand is 23bit. Of course, if clipping-resistance is not important (special precaucions like keeping signal level in range of e.g. -6db or -12db could emulate it). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [ANN] QjackCtl 0.5.5 - A Black-Friday'18 Release
Wholly greetings! QjackCtl 0.5.5 (black-friday'18) is released! QjackCtl [1] is a(n ageing yet modern, not so 'simple' anymore) Qt [2] application to control the JACK [3] sound server, for the Linux Audio [5] infrastructure. Website: https://qjackctl.sourceforge.io http://qjackctl.sourceforge.net Project page: http://sourceforge.net/projects/qjackctl Downloads: http://sourceforge.net/projects/qjackctl/files - source tarball: http://download.sf.net/qjackctl/qjackctl-0.5.5.tar.gz - source package (openSUSE Tumbleweed): http://download.sf.net/qjackctl/qjackctl-0.5.5-34.rncbc.suse.src.rpm - binary package (openSUSE Tumbleweed): http://download.sf.net/qjackctl/qjackctl-0.5.5-34.rncbc.suse.x86_64.rpm - AppImage [7] package: http://download.sf.net/qjackctl/qjackctl-0.5.5-6.x86_64.AppImage Git repos: https://git.code.sf.net/p/qjackctl/code https://github.com/rncbc/qjackctl.git https://gitlab.com/rncbc/qjackctl.git https://bitbucket.com/rncbc/qjackctl.git Change-log: - Old deprecated Qt4 build support is no more. - Graph port sort options added as View / Sort menu. - System tray options now subject to current desktop environment availability. - Also disable Setup / Misc / Other / Save JACK server configuration to (.jackdrc) when JACK D-Bus interface is enabled. - Whether to use server synchronous mode option added to Setup / Settings / Parameters (only applied when JACK D-BUS interface is enabled). - Disable some Setup / Settings / Advanced parameters when JACK D-Bus interface is enabled and vice-versa. - Attempt to power-cycle JACK D-Bus service on demand; - Marked as probably useless anyway, old "H/W Monitor" option (-H) is now being ditched from Setup / Settings / Advanced tab. - Graph port/connections highlighting. License: QjackCtl [1] is free, open-source Linux Audio [5] software, distributed under the terms of the GNU General Public License (GPL) version 2 or later [6]. See also: http://www.rncbc.org/drupal/node/1953 References: [1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface https://qjackctl.sourceforge.io http://qjackctl.sourceforge.net [2] Qt framework, C++ class library and tools for cross-platform application and UI development http://qt.io/ [3] JACK Audio Connection Kit http://jackaudio.org [4] ALSA, Advanced Linux Sound Architecture http://www.alsa-project.org/ [5] Linux Audio consortium of libre software for audio-related work http://linuxaudio.org [6] GPL - GNU General Public License http://www.gnu.org/copyleft/gpl.html [7] AppImage, Linux apps that run anywhere http://appimage.org/ Enjoy && keep having fun! -- rncbc aka Rui Nuno Capela ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
It could be lame question, but still... is it possible, that some
implementations (compiler/hardware) will print 1? (even 64bit doesn't
hold 20 decimal digits).?
In Fri, 23 Nov 2018 14:09:02 +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..
>
> float a = (1 + 1e20) - 1e20;
> float b = 1 + 1e20; b -= 1e20;
> printf ("%f %f\n", a, b);
>
> Any guesses what this code prints without compiling it? :)
>
> > I was using O3. Following on from this I found that if I removed
> > either O3 or ffast-math the problem disappeared.
>
> OK, so SSE/AVX/compiler-intrinsics are the issue at hand.
>
> > It's quite possible that I'm over-thinking this as there are
> > actually only a few iterations before the initial figures are
> > re-calculated, but I don't like mysteries :(
> >
>
> You could also disable this for a specific function only
>
> __attribute__((optimize("-fno-fast-math")))
> void different_mysteries_here (float val)
> {
> ...
> }
>
> ciao,
> robin
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
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...? -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
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..
float a = (1 + 1e20) - 1e20;
float b = 1 + 1e20; b -= 1e20;
printf ("%f %f\n", a, b);
Any guesses what this code prints without compiling it? :)
> I was using O3. Following on from this I found that if I removed either O3 or
> ffast-math the problem disappeared.
OK, so SSE/AVX/compiler-intrinsics are the issue at hand.
> It's quite possible that I'm over-thinking this as there are actually only a
> few iterations before the initial figures are re-calculated, but I don't like
> mysteries :(
>
You could also disable this for a specific function only
__attribute__((optimize("-fno-fast-math")))
void different_mysteries_here (float val)
{
...
}
ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is -ffast-math safe for audio?
On Thu, 22 Nov 2018 23:29:11 +0100
Robin Gareus wrote:
>Hi Will,
>
>I just ran your code and -ffast-math does not make any difference.
>
>With or without --ffast-math I get "int: 5 rem: 0.049994"
>
>However optimizing the code with `-O2 --ffast-math` does make a
>difference because SSE is used.
>
>Do you also use -O2, or -O3 along with --fast-math?
>
>On 11/22/2018 06:30 PM, Will Godfrey wrote:
>[...]
>> My suspicion is that the difference is due to accumulated rounding
>> errors.
>>
>> Curiously without the decrements the behavior with and without
>> -ffast-math seems to be identical well into the millions.
>Yep. you do loose precision. In IEEE 32bit float, there is no 0.1.
>
>0.1 would be approximated as (13421773) * 2^(-27), and 0.05 as
>(13421773) * 2^(-28) and truncated.
>
>Note that this is an odd number. The last bit of the mantissa
>(0x004d) is lost when the exponent changes.
>
>A simpler example to show this is
>
>#include
>#include
>int main (int argc, char** argv) {
> float a = 0;
> for (int i = 0; i < 100; ++i) {
>a += 0.1f;
>a -= 0.05f;
>a = fmodf (a, 1.f);
> }
> printf ("%f\n", a);
> return 0;
>}
>
>using gcc 6.3.0-18+deb9u1, x86_64, this
>prints 1.00 (when compiled with -O0)
>and0.01 (when compiled with -O2 --fast-math)
>
>
>The difference here is that the former calls fmodf(), while in the
>latter, optimized, case the compiler uses cvtss2sd SSE instead. The
>internal limits of float precision differ for those cases.
>
>
>--ffast-math issues in audio-dsp are usually due to re-ordering and
>reciprocal approximations. e.g. instead of (x / 2) the compiler calls
>(0.5 * x), which can lead to different results if the inverse value does
>not a precise floating point representation. e.g. 1.0 / 0.1 != 10.0
>
>A good read on the subject is
>http://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf (Goldberg,
>David: "What Every Computer Scientist Should Know About Floating-Point
>Arithmetic").
>
>If you were change the two constants to
> a += 0.5f;
> a -= 0.25f;
>the issue vanishes.
>
>Cheers!
>robin
Thanks for going into this in such detail Robin. I never realised fp stuff
could be *quite* so, umm, approximate!
I was using O3. Following on from this I found that if I removed either O3 or
ffast-math the problem disappeared.
It's quite possible that I'm over-thinking this as there are actually only a
few iterations before the initial figures are re-calculated, but I don't like
mysteries :(
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
