Failing tests with Rubber Band v1.9.1

[Uwe Klotz]

See also: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/Rubberband.20test.20failures

Now confirmed for local builds after upgrading from v1.9.0 to v1.9.1:

Note: Google Test filter = EngineBufferE2ETest.RubberbandReverseTest
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from EngineBufferE2ETest
[ RUN ] EngineBufferE2ETest.RubberbandReverseTest
info [CachingReaderWorker 1] SoundSourceFFmpeg - Unknown channel layout -> using default layout 4 for 1 channel(s)
info [CachingReaderWorker 2] SoundSourceFFmpeg - Unknown channel layout -> using default layout 4 for 1 channel(s)
info [CachingReaderWorker 3] SoundSourceFFmpeg - Unknown channel layout -> using default layout 4 for 1 channel(s)
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
WARNING: MovingMedian: NaN encountered
corrupted size vs. prev_size

[Uwe Klotz (uklotzde-deactivatedaccount)]

https://github.com/breakfastquay/rubberband/issues/37

[Uwe Klotz (uklotzde-deactivatedaccount)]

Marked as critical until we know more about the consequences, because the last line of the output sounds worrisome.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Patch for Fedora: https://src.fedoraproject.org/rpms/rubberband/pull-request/1

[OsZ (toszlanyi)]

After a few attempts with mixxx --logLevel debug I got this error on the console while loading the sampler TC_20.mp3 (but all others as well) to the sampler bank. interesting enough the last error message sounds familiar:
```
corrupted size vs. prev_size while consolidating
Abgebrochen (Speicherabzug geschrieben)
```
all console log for loading that specific file is attached, mixxx.log doesn't show any info...

I found it to be reproducible now by loading any kind of tracks into decks from the library: Computer -> Qick Links in case the track is not analyzed yet. Regardless of the Deck or Sampler bank. If I open a not-analyzed track into the deck that uses Key Lock then it hangs and most of the time locks the whole system. If I switch off Key Lock for another deck and try to load another track that is not analyzed yet then it doesn't crash or even hang.

[OsZ (toszlanyi)]

one more information: dmesg once showed me

segfault at 0 ip 00007f6a643f60d0 sp 00007f69137fd258 error 4 in libfftw3.so.3.6.9[7f6a642f6000+1e7000]

which is not really reproducible when the system hangs completely. I also copied the info to the zulip chat here: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/Rubberband.20test.20failures/near/236060164

[Uwe Klotz (uklotzde-deactivatedaccount)]

That's the bug and I already pointed out why I think it is critical. Your crash confirmed it.

[OsZ (toszlanyi)]

After some testing with fftw v 3.3.8-3 I can confirm no crashes anymore while mixing for more than 2 hours with non-analyzed tracks. Just out of curiosity I changed back fftw to v 3.3.9 and first track loaded crashed Mixxx. So it is quite obvious to me that new fftw+rubberband version causing the issue and older versions don't. To bind Mixxx to older versions of the dependencies could be a interim fix but a better compatibility to newer rubberband and fftw would be appreciated. Cheers!

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/10377