Loops fall out of sync

[Kiefer Waight]

Loop constraints fall out of sync when being beat matched. I tested this by playing the exact same song on both channels. I synchronized both songs and selected 4 bar loop on one channel. The looped channel began to inch out of sync with the other channel.

Tested on Windows 7 32-bit Latest Branch Compiled on 5/31/2011

[jus (jus)]

Confirmed, the shorter the loop , the faster they get out of sync. On every loop cycle they waste a little time.

[losky (loskylp)]

I can confirm to the bug but in a diferent way
In my case if the same song is in a 4 bar loop in the 2 tracks it does't get out of sync
But if track 1 is in a 4 bar loop and track 2 is in a 8 bar loop, the 4 bat loop waste double time that 2nd track
after 2 or 3 loops it is realy evident the mismatch

It gets imposible to get 1 track on loop and a 2nd playing normaly becouse they will get out of sync

[losky (loskylp)]

im on linux 32 bit Debian stable
using 1.10-beta from bzr

[RJ Skerry-Ryan (rryan)]

Is this also present in Mixxx 1.9.0?

[jus (jus)]

It is not present in v1.9.0 cause the "Constrain loop length to a multiple of beats" feature was introduced past 1.9.0.

[RJ Skerry-Ryan (rryan)]

Ugh, yes. I'm upgrading this to high since loops are actually broken. I have a suspicion about why, but it's a pretty fundamental issue with the way stuff in the engine currently fits together.

[RJ Skerry-Ryan (rryan)]

My suspicion was correct and I have a band-aid that fixes it when keylock is off.

I just verified the fix by loading the same song into both decks and setting a 1-beat loop on both sides, syncing them, and then releasing the second from the loop. The first deck stayed in sync with the second deck for the entire duration of the song.

[Phillip Whelan (pwhelan)]

What is the fix? Does it have something to do with the workaround in ScaleST or is it a problem with playpos being rounded?

[RJ Skerry-Ryan (rryan)]

Rather than write another writeup of what is going on I'll just post my new comment in EBSL.

    // RAMAN follows loops. delta_raman_samples is almost always equal to what
    // EBSL estimates as new_playpos. The difference is that EBSL calculates
    // new_playpos as the total number of samples read, while EngineBuffer wants
    // to know (from getNewPlaypos()) the total delta position the scaler has
    // traversed in the song to produce its output, not the total number of song
    // samples traversed. Since EBSL is not a read-ahead scaler, there is a
    // direct correspondence between RAMAN playposition and samples output
    // during this scale() call. If we take the song position before reading
    // from the RAMAN (as we do at the start of scale()) and take the difference
    // with its current position, we will get the total delta position the
    // scaler has traversed in the song to produce its output. The old way (just
    // leaving new_playpos as calculated by EBSL) causes loops to fall out of
    // sync (Bug #790871) because at the end of a loop, RAMAN takes the loop
    // while we are calling getNextSamples() on it. RAMAN's internal position is
    // therefore *at or after the loop's start or end position*, depending on
    // whether we are in reverse. EBSL then says to EngineBuffer that we have
    // travelled new_playpos samples, which EngineBuffer then adds to its
    // current playposition. This puts EngineBuffer's playposition PAST the end
    // of the loop. EngineBuffer then calls process() on all EngineControls and
    // LoopingControl tells EngineBuffer to jump to the loop start or end
    // position. EngineBufer updates its playposition and calls
    // RAMAN::notifySeek() to seek the RAMAN *to the start or end of the
    // loop*. Recall from above that the RAMAN was already at or after the
    // loop's start or end position. This causes the RAMAN to replay samples on
    // every run through a loop, causing the loop to drift out of sync with
    // other decks and possibly causes a tiny audible blip if the waveform is
    // discontinuous. This is a giant mess and needs to be fixed with a rework
    // of how the RAMAN, EngineBuffer, and the Scalers work together.
    //
    // rryan 10/2011

[RJ Skerry-Ryan (rryan)]

I'm committing my fix to the 1.10 branch and trunk. I'm thinking of marking WontFix in 1.9.x because this could have stability repercussions I don't comprehend right now.

[Phillip Whelan (pwhelan)]

From what I remember, part of the problem between EBSL and RAMAN is that you cannot do read ahead seeks, you can only ask for the samples you're going to process. This also rules out any kind of antialiasing or smoothing.

[RJ Skerry-Ryan (rryan)]

Fixed this properly now for both keylock and non-keylock. I left a keylock'd loop going synced to a non-keylocked loop for 1+ hours with no audible desync.

[RJ Skerry-Ryan (rryan)]

Not going to fix in 1.9 since it is a fairly risky change to the engine.

[jus (jus)]

This bug is exactly as described in the original report in trunk again as of lp:mixxx r3205

[Swiftb0y (swiftb0y)]

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