Stuck at max volume on latest version from github

[reidevries]

Running wolf-shaper-git from AUR, on the latest version, in Ardour 7 on Linux, and any track that I put wolf shaper on has its volume meter maxed out, and no audio comes thru from any tracks at all. I think for some reason wolf shaper is outputting a constant +1.0 or -1.0 value, which causes all audio to get clipped to the max/minimum. I switch to the non-AUR build which I think is the latest release build, and that one works, so this must have been a fairly recent issue.

[reidevries]

Hmm, seems that the latest binary version also is broken, but in a different way. This time, if I manipulate the oversampling control, the audio stops (but without the DC clipping.) I imagine the issues might be related

[reidevries]

Can confirm this happens with both the LV2 and VST3 versions

[reidevries]

Just tried the 1.0 release, that one works

[pdesaulniers]

Thanks for reporting this issue! I can reproduce the bug with the oversampling control. I will look into it.

[pdesaulniers]

At first I suspected an UB issue, but it seems like Valgrind does not detect memory errors in this specific case.

I can reproduce the issue when the plugin is built with GCC 13.1.1 and optimizations are enabled. I cannot reproduce the issue when DEBUG=true. I cannot reproduce with Clang either.

Also, I cannot reproduce the issue when the plugin is built with CMake instead of the default Makefile!

So, I assume this is either related to a compiler flag or some kind of UB that Valgrind is not detecting.

[pdesaulniers]

Somehow, the issue appears to be caused by the flag -ffast-math.

I have temporarily added -fno-fast-math to the compiler flags, and now the oversampling control does not cause the plugin to go silent anymore (at least, on my machine)

[pdesaulniers]

More specifically, the issue seems related to -ffinite-math-only, which is enabled by -ffast-math.

Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs.

This option is not turned on by any -O option since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.

The default is -fno-finite-math-only.

DSPFilters makes use of +-Infs for some of its calculations, so it is not compatible with this compiler flag.

wolf-shaper/libs/DSPFilters/include/DspFilters/MathSupplement.h

Lines 63 to 66 in d34289f

	inline const complex_t infinity()
	{
	return complex_t (std::numeric_limits<double>::infinity());
	}

It would probably make sense to build the plugin with -fno-finite-math-only, or to modify DSPFilters so that it doesn't depend on Inf.

But then, according to some quick tests, -ffast-math doesn't appear to bring significant performance improvements on my machine, so I'm not sure if it is worth the trouble...