Comment by ~breakfastquay on ~breakfastquay/rubberband
I've added a test in the Meson build, in a branch called
libatomic-check. I'd appreciate feedback - especially as I haven't actually seen this failure myself!The test works (if it works) by using the C++ compiler to compile and link the same thing that the actual Rubber Band code uses, namely declaring variables of types
std::atomic<double>andstd::atomic<int>and callingis_lock_freeon each - since that is the symbol that both bug reports had in common.
Comment by ~breakfastquay on ~breakfastquay/rubberband
It turned out the tests failed in any build using resamplers other than the built-in one (see also https://github.com/breakfastquay/rubberband/issues/83 ). However there was a further failure specific to 32-bit builds as well!
Those are now fixed - I hope! - in today's 3.2.1 release.
REPORTED RESOLVED CLOSED
Comment by ~breakfastquay on ~breakfastquay/rubberband
abi_x86_32.x86
This is a 32-bit build?
(A 32-bit build should work of course, but that would explain why there might be differences and why I might not have noticed them!)
Comment by ~breakfastquay on ~breakfastquay/rubberband
This is in test in the
performancebranch now (in hg).OptionWindowShortcuts out all the multi-window processing, using only the single window size already in use for the classification analysis work. So it does more sophisticated analysis than R2 but has comparable processing requirements.
general enhancement added by ~breakfastquay on ~breakfastquay/rubberband
future feature removed by ~breakfastquay on ~breakfastquay/rubberband
future feature added by ~breakfastquay on ~breakfastquay/rubberband
performance added by ~breakfastquay on ~breakfastquay/rubberband
Ticket created by ~breakfastquay on ~breakfastquay/rubberband
The R3 code has a phase reset across bins happening gradually whenever the stretch factor returns to 1.0. Backport this to R2.
performance added by ~breakfastquay on ~breakfastquay/rubberband