waveform stutters during drag'n'drop on Win7

Bug #1300664 reported by Max Linke on 2014-04-01
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

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

Max Linke (max-linke) on 2014-04-01
Changed in mixxx:
importance: Undecided → Critical
status: New → Confirmed
milestone: none → 1.12.0
Max Linke (max-linke) on 2014-04-05
tags: added: windows
kramer (default-kramer) wrote :

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.

kramer (default-kramer) on 2014-07-19
Changed in mixxx:
assignee: nobody → kramer (default-kramer)
jus (jus) wrote :

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) wrote :

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) wrote :

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.

Changed in mixxx:
status: Confirmed → In Progress
kramer (default-kramer) on 2014-07-21
Changed in mixxx:
status: In Progress → Fix Committed
Max Linke (max-linke) wrote :

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.

Changed in mixxx:
status: Fix Committed → In Progress
kramer (default-kramer) wrote :

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.

kramer (default-kramer) on 2014-07-24
Changed in mixxx:
assignee: kramer (default-kramer) → nobody
Max Linke (max-linke) on 2014-11-04
Changed in mixxx:
status: In Progress → Triaged
Changed in mixxx:
milestone: 1.12.0 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers