Open dvzrv opened 1 year ago
Thanks for the report...
A similar failure has been reported at https://todo.sr.ht/~breakfastquay/rubberband/27 but because that was in a 32-bit build, I was waiting until I had a moment to dig out a 32-bit environment to test it.
Which was stupid of me, because now that I have this report as well, and I know Arch no longer does 32-bit builds, I can immediately reproduce it - it happens always when using libsamplerate instead of the default built-in resampler. Duh. I wonder why this is not checked in CI - this configuration is built but I guess the tests are not being run within it.
I'll look into this during the week. You could build with the built-in resampler (and the tests should then pass) but perhaps it's better to wait for a fix. The fix might just be to make the test less stringent, but I don't know for sure yet. Sorry about this.
No worries! Thanks for the prompt reply! :) I can wait a bit :)
There's a 3.2.1 out now with fixes. I hope...
everything is fixed, except this same thing still fails on 32-bit x86:
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
stdout:
Running 69 test cases...
../src/test/TestStretcher.cpp(951): error: in "TestStretcher/impulses_fast_samepitch_realtime_finer": check peak0 < int(ceil(200 * timeRatio)) has failed [100 >= 100]
stderr:
*** 1 failure is detected in the test module "RubberBand"
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――***
with mostly the same configuration
Rubber Band Library 3.2.1
Directories
prefix : /usr
bindir : bin
libdir : lib
datadir : share
Configuration
FFT : FFTW
Resampler : libsamplerate
Build type : Release
Architecture : x86
Build targets
Static library : YES
Name: rubberband
Dynamic library : YES
Name: rubberband
JNI library : NO
LADSPA plugin : YES
Name: ladspa-rubberband
LV2 plugin : YES
Name: lv2-rubberband
Vamp plugin : YES
Name: vamp-rubberband
Command-line utility (R2): YES
Name: rubberband
Command-line utility (R3): YES
Name: rubberband-r3
Unit tests : YES
Name: tests
User defined options
auto_features : auto
bindir : /usr/bin
buildtype : release
datadir : /usr/share
includedir : /usr/include
infodir : /usr/share/info
libdir : /usr/lib
libexecdir : /usr/libexec
localedir : /usr/share/locale
localstatedir : /var
mandir : /usr/share/man
prefix : /usr
sbindir : /usr/sbin
sharedstatedir : /var/lib
sysconfdir : /etc
wrap_mode : nodownload
b_lto : true
b_pie : true
b_staticpic : true
fft : fftw
resampler : libsamplerate
there's also a failure on the ppc64le architecture:
Running 69 test cases...
../src/test/TestStretcher.cpp(958): error: in "TestStretcher/impulses_slow_lower_realtime_finer": check peak2 > int(ceil(9770 * timeRatio)) has failed [77399 <= 78160]
../src/test/TestStretcher.cpp(958): error: in "TestStretcher/impulses_slow_lower_realtime_finer_hcpitch": check peak2 > int(ceil(9770 * timeRatio)) has failed [77399 <= 78160]
stderr:
*** 2 failures are detected in the test module "RubberBand"
That's odd, I did test x86... wonder what I've missed there.
I have no means of testing ppc. As you can see in many cases the precise values are quite sensitive to the configuration of various mathematical libraries - and that's normal and acceptable - so the aim in these particular tests is to check that the results are being produced at all and "are plausible" rather than to check anything with precision. It's "are plausible" where the problems lie!
to be specific, it's against musl libc, on alpine linux. the full log is https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1005027
As you can see in many cases the precise values are quite sensitive to the configuration of various mathematical libraries
oh certainly- initially it was using builtin fft/resampling and the tests passed then. they only fail in release mode without builtins (for ppc64le specifically; x86 just always fails)...
Just wanted to note that it fixed it for my use-case (x86_64). Thanks @cannam!
Perhaps this is fixed by https://github.com/breakfastquay/rubberband/commit/df596f472e3271ad64ab6c2968920e5e95c17080?
for 32-bit x86 yes, for ppc64le it's the same
Hi @cannam! When trying to upgrade to 3.2.0 for Arch Linux I ran into the issue of the test "Stretcher" failing.
Output from build/meson-logs/testlog.txt:
I'm not entirely sure what to do with this, maybe you have an idea?