waveform stutters during drag'n'drop on Win7

[Max Linke]

I always get stuttering waveforms when I drag'n'drop tracks. I don't see any of this under linux

[kramer (default-kramer)]

I can reproduce this (32-bit Mixxx on Win7 64). In fact, I get occasional stuttering all the time and heavy stuttering during drag and drop. It seems to affect all skins.

I'd be willing to try to fix this but I think I should try tackling some easy bugs first.

[jus (jus)]

See this on OS X too, probably related to"GUI stutters if you click in sidebar or scroll through library", lp:685795

[kramer (default-kramer)]

Did some investigation - the problem has at least 2 parts. The first problem is around this line:

    int usRefToVSync = vsyncThread->usFromTimerToNextSync(&data.m_referenceTime);

When "data.m_referenceTime" is newer than the VSync thread's "m_timer" the resulting call to "PerformanceTimer::difference()" underflows an unsigned int, resulting in a huge "offset" which is used on this line:

    playPos += data.m_positionStep * offset * data.m_rate / m_dAudioBufferSize / 1000;

so the playPos jumps way too far ahead.

The first part is to fix this underflow, define what "difference()" should return in this case, and in general, handle the case where "data.m_referenceTime" is newer than the vsync thread's "m_timer" .

The 2nd part is this. I fixed the underflow and the playPos no longer jumps around. But the waveform (appears to) run at a very low framerate. I'm guessing the VSync thread is getting starved.

[kramer (default-kramer)]

I submitted pull request 292 for the stuttering waveform issue specifically. https://github.com/mixxxdj/mixxx/pull/292

I created bug #1345220 for the overall UI slowdown that occurs when dragging.

[Max Linke (max-linke)]

This is the bug for UI-slowdown when dragging, the titel is quite clear about that. So please keep any discussions about this in here.

Nice fix for the general stutter that you got though thanks.

[kramer (default-kramer)]

Well I've made some progress... I need to dump my brain because it's getting full and I have other stuff to do for a while.

First, this problem existed in the 1.11.0 release, although it may have been less noticeable. Second, as long as you keep the mouse moving quickly it doesn't happen. It's only when you hold a drag still.

The problem is that the GUI thread is waiting. (And the VSync thread is waiting on the GUI thread via semaphores, but that's not relevant.) There's plenty of CPU available too, so something is blocking. I ran the Very Sleepy profiler and you can see in the attached screenshot that "DoDragDrop" in ole32 is the culprit. This probably explains why the problem doesn't affect Linux (ole32 is a standard windows module).

This really looks like a flaw in Qt - I'm pretty sure they did not want to make a blocking call here. But perhaps they have no choice on Windows?

Does anyone have a Qt5 Windows version they can test? It would be interesting to see if the problem exists with Qt5.

[Daniel Schürmann (daschuer)]

Lowering Priority, because this is no party stopper.

[Swiftb0y (swiftb0y)]

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