DEBUG_ASSERT: EngineBufferTest.SlowRubberBand

[Uwe Klotz]

Branch: master (2.1.0-pre-alpha)
OS: Fedora 23 x86_64

Since I didn't get any replies from the mailing list weeks/months ago I'm filing this test failure as a bug now ;) It's just a debug assertion, but I always compile Mixxx with debug_assertions_fatal=1 to detect such issues early during development!

[ RUN ] EngineBufferTest.SlowRubberBand
Loading resources from "/home/uk/Projects/Mixxx/mixxx/res/"
ConfigObject: Could not read "/home/uk/Projects/Mixxx/mixxx/src/test/test_data/test.cfg"
Compressor attack per frame: 0.000408163 decay per frame: 4.08163e-05
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTickTime" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTick50ms" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTickTime" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTick50ms" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTickTime" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTick50ms" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTickTime" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTick50ms" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTickTime" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTick50ms" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTickTime" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTick50ms" )
ControlObject "[PreviewDeck1]" "input_configured" already created
ControlObject "[PreviewDeck1]" "passthrough" already created
ControlObject "[PreviewDeck1]" "pregain" already created
ControlObject "[PreviewDeck1]" "replaygain" already created
ControlObject "[PreviewDeck1]" "play" already created
ControlObject "[PreviewDeck1]" "loop_start_position" already created
ControlObject "[PreviewDeck1]" "loop_end_position" already created
ControlObject "[PreviewDeck1]" "vinylcontrol_status" already created
ControlObject "[PreviewDeck1]" "vinylcontrol_enabled" already created
ControlObject "[PreviewDeck1]" "file_bpm" already created
ControlObject "[PreviewDeck1]" "file_key" already created
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTickTime" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTick50ms" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTickTime" )
ControlDoublePrivate::getControl returning NULL for ( "[Master]" , "guiTick50ms" )
DEBUG ASSERT: "filepos_play_rounded == m_filepos_play" in file src/engine/enginebuffer.cpp, line 977

[Uwe Klotz (uklotzde-deactivatedaccount)]

scons \
prefix=/usr/local \
qt5=0 \
qdebug=1 \
optimize=native \
tuned=1 \
debug_assertions_fatal=1 \
faad=1 \
opus=1 \
shoutcast=1 \
modplug=1 \
wv=1 \
ffmpeg=1 \
test=1

[Uwe Klotz (uklotzde-deactivatedaccount)]

As a consequence of this long outstanding issue I propose to set debug_assertions_fatal=1 in Travis builds to detect such issues early during development! Otherwise no one will notice or take care.

[Uwe Klotz (uklotzde-deactivatedaccount)]

https://github.com/mixxxdj/mixxx/pull/954

[RJ Skerry-Ryan (rryan)]

+1 to setting debug assertions fatal on Jenkins. Do we know why the assertion is failing? In the past this rounding issue has caused trouble which is why we put the assert in there.

[RJ Skerry-Ryan (rryan)]

Er Jenkins -> Travis

[Owen Williams (ywwg)]

I would prefer to do a git bisect to discover why this test has started failing before papering it over. Is there an old commit (say, around january) where the test succeeds on your system? (Note that you can even automate git bisect by passing ./mixxx-test as the script for it to run)

[Uwe Klotz (uklotzde-deactivatedaccount)]

I will do a git bisect as suggested.

[Uwe Klotz (uklotzde-deactivatedaccount)]

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
e1995299dc7a85b386bc5d561f93279136d77c9d
e8009de392d04bf02ef51d63787ce264709bed02
a56c50dd3d967c1be4ad3683c682c1d925449792
We cannot bisect more!

[Owen Williams (ywwg)]

These are all good candidates because they all touch the engine buffer code. Why is it not possible to tell which one introduces the problem? Or are these the ones you had to skip?

[Uwe Klotz (uklotzde-deactivatedaccount)]

I think this is a general issue caused by the mixture of sample vs. frame calculations with implicit assumptions about number of channels that can be found everywhere in the Mixxx code base.

This is getting even worse when dealing with the floating-point calculations like here in the scaler code. I trying to do the floating-point calculations in frames instead of samples and only convert to samples once.

[Daniel Schürmann (daschuer)]

Thank you for you investigations.
I have already started an project that uses doubles for a all position information inside Mixxx.
https://github.com/daschuer/mixxx/commits/positionrounding2
But unfortunately it get stucked, because it is blocked by this unmerged PR
https://github.com/mixxxdj/mixxx/pull/552 waiting for review.

IMHO it is wrong to round the track position to full frames at all, because we actually can stop a track between two samples if we play slow and scaling is involved. So we should use double frames when ever possible.
The only time rounding should be don is when passing the scaled samples to the output buffer.

[Owen Williams (ywwg)]

Indeed, the linear scalar relies on sub-sample position to provide accurate scaling across the buffer boundary.

[Uwe Klotz (uklotzde-deactivatedaccount)]

That's what I just did, not rounding the positions. But I did not notice that you already worked on that, Daniel.

[Swiftb0y (swiftb0y)]

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