waveform uneven / choppy after editing metadata in track table on macOS

[Foss-4]

MacBook Pro 2011, macOS 10.12.3, mixxx 2.1.0-alpha-pre from 2017-02-15

Waveform shows fine, I can play, mix, work with tracks, add to crates etc, but whenever I (most times accidentally via trackpad) go into editing a track name (often I want to add the track to a crates but instead of two finger tap for contextual menu, a three fingertap is registered, which may be correct since two fingers + thumb are working on the trackpad) the waveform is displayed very choppy, close to unusable.

As odd as above behavior may sound, it is 100% reproducible. If any dev wants to inspect this, screensharing is possible.

Interesting observation: as soon as any other window (or dialog) is in focus, mixxx shows the waveforms perfectly fine again. But only as long as that other window is in focus. Once I switch back to mixxx, the choppyness is back.

see screencast attached.

[Be (be.ing)]

Does this happen with Mixxx 2.0 using the same waveform renderer?

[Foss-4 (foss-4)]

Not happening on 2.0 so regression.

[Foss-4 (foss-4)]

no longer happening with latest master build. please close as worksforme.

[Be (be.ing)]

Reported as not working again by the original poster and another user in the forums:
http://mixxx.org/forums/viewtopic.php?f=3&p=32395

[Foss-4 (foss-4)]

 (again) no longer happening with latest master build. please close as worksforme.

[jus (jus)]

Setting status to OPINION, so it will show up in the default search. Status INVALID would not. Just in case it returns.

[Foss-4 (foss-4)]

And it does return. See attached screencast.

Note two things from the screencast:

1. to reproduce: double tap on the title of a track with two fingers. that goes into editing mode to edit the title. as soon as that happens the waveform becomes choppy.

2. note that as soon as any dialog is displayed by mixxx (in the screencast I use the quit dialog to demonstrate this) the waveform is perfectly smooth again. close dialog, waveform is back to choppy.

Both are 100% reproducible.

[Foss-4 (foss-4)]

This is the most annoying bug I'd assume using mixxx on macOS since during regular usage, by accident you can run into the editing mode of some text in the playlist when using the trackpad of the laptop. The user then ends up with the unusable waveforms. Depending on the situation this can be a serious problem.

Is there any information I can provide to help developers to address this problem? Seems most devs are not on macOS. Sadly no dev skills on my end :/

[Daniel Schürmann (daschuer)]

Hopefully we find a mac OS contributor during the beta phase.

[Benis (beenisss)]

I have the exact same issue, running macOS 10.13.3 - happy to help if I can, have just set up Eclipse etc. and have been taking a look at the code.

[Foss-4 (foss-4)]

Benis is this issue something you would want to work on? As Daniel pointed out, it seems the core devs are having a hard time debugging this since no one is using macOS.

[Be (be.ing)]

I would be surprised if this actually fixes the issue, but the impact of this should be alleviated by https://github.com/mixxxdj/mixxx/pull/1550

[Benis (beenisss)]

I'd be happy to do what I can, I mean I'm new to C++ and debugging multi-thread applications so it won't be a quick turnaround, but if you give me some pointers as to what kind of thing I should be looking for I'll take a look.

[Benis (beenisss)]

Some pretty weird observations from my initial look at this:

* Deck 1 and Deck 2 are affected differently. The waveform for deck 1 has distinct, regular stutters. Deck 2 is just constantly choppy. It does seem to follow a consistent 'tempo', but is very different to Deck 1.
* The rate of glitching, on Deck 1 at least, inversely correlates with track length. The shortest track in my collection is a little over a minute. The longest track in my collection is about 15 minutes long and the glitches happen at a rate of about 40 a minute.

[Benis (beenisss)]

Oops, managed to submit that comment prematurely. For the short track I mentioned above it's more like 300-400 a minute. I've checked some tracks in between to make sure the pattern is consistent, which it is.

[Be (be.ing)]

Pushing this back to 2.2 since it doesn't seem we have any ideas what is going on and the impact of this has been reduced by https://github.com/mixxxdj/mixxx/pull/1550

[Daniel Schürmann (daschuer)]

Can we identify a version where this was introduced?
Can one test Mixxx 2.0 again?

mixxx-2.1.0-alpha-pre-master-git6202-release-macintel64.dmg effected.

How about:
mixxx-2.1.0-alpha-pre-master-git5971-release-macintel64.dmg ?

[Be (be.ing)]

I cannot reproduce this with build r6592.

[Be (be.ing)]

I tested build r6549 on another Macbook with build r6592 and did reproduce this. Hardware info:

  Model Name: MacBook Pro
  Model Identifier: MacBookPro13,3
  Processor Name: Intel Core i7
  Processor Speed: 2.6 GHz
  Number of Processors: 1
  Total Number of Cores: 4
  L2 Cache (per Core): 256 KB
  L3 Cache: 6 MB
  Memory: 16 GB
  Boot ROM Version: MBP133.0238.B00
  SMC Version (system): 2.38f7

macOS 10.13.3

[Daniel Schürmann (daschuer)]

What can exactly can you reproduce? That r6592 fixes the issue?

[Be (be.ing)]

Sorry, I am not sure where the "r6549" came from in my last comment. I have tried build r6592 on three Macbooks now:
#1: MacBook Air (11-inch, Early 2015): 1.6 GHz Intel Core i5, 4 GB 1600 MHz DDR3, Intel HD Graphics 6000 1536 MB

#2: Macbook (15 inch, 2016):
  Model Name: MacBook Pro
  Model Identifier: MacBookPro13,3
  Processor Name: Intel Core i7
  Processor Speed: 2.6 GHz
  Number of Processors: 1
  Total Number of Cores: 4
  L2 Cache (per Core): 256 KB
  L3 Cache: 6 MB
  Memory: 16 GB
  Boot ROM Version: MBP133.0238.B00
  SMC Version (system): 2.38f7

#3: Macbook Air (13 inch, mid 2011)
  Model Name: MacBook Air
  Model Identifier: MacBookAir4,2
  Processor Name: Intel Core i5
  Processor Speed: 1.7 GHz
  Number of Processors: 1
  Total Number of Cores: 2
  L2 Cache (per Core): 256 KB
  L3 Cache: 3 MB
  Memory: 4 GB
  Boot ROM Version: MBA41.007B.B00
  SMC Version (system): 1.73f66

I could only reproduce the bug on Macbook #2. As written in the original description of this bug, the waveforms became choppy after the inline editing of metadata in the track table was activated. When focus was switched to another window, the waveforms were smooth. The waveform choppiness persisted until Mixxx was restarted and happened every time after activating the metadata editing in the track table.

[Daniel Schürmann (daschuer)]

So https://github.com/mixxxdj/mixxx/pull/1566 does not make any difference?
Could you identify a build that introduces the issue?
How about the versions linked in #18?

[Be (be.ing)]

I have not tested any builds from before https://github.com/mixxxdj/mixxx/pull/1566 was merged. But this is still an issue. This has been an issue for a long time now and I'm not going to bother figuring out when the bug was introduced right now. For 2.1 we can work around it by simply turning off metadata editing in the track table by default.

[Daniel Schürmann (daschuer)]

Since you have hardware access right now, it would be really nice to know.

[Benis (beenisss)]

I have been looking at this also, though I'm still getting to grips with debugging etc. As it doesn't happen when the app doesn't have focus it's a bit difficult to interrogate, because as soon as you go back to your debugging window the issue goes away. So I've been getting around this by pasting a sleep command followed by an interrupt command into the debug prompt, so that I have time to switch back to the app. Don't know if this is necessary or not but any tips are welcome.

As I said above, on deck one this produces distinct, regular stutters. I used the Instruments tool that comes with XCode which shows that CPU use is spiking a few times a second in line with this.

I think this might actually be related to drawing of the white rectangle/blue border that appears when you edit a field in place, though I can't think why. I've been trying to find where in the code this is triggered so that I can eliminate it but I haven't yet.

[Foss-4 (foss-4)]

"the waveforms became choppy after the inline editing of metadata in the track table was activated. When focus was switched to another window, the waveforms were smooth. The waveform choppiness persisted until Mixxx was restarted and happened every time after activating the metadata editing in the track table."

that's the behavior I have been seeing for over a year and even before filing this bug.

I am a bit worried installing 2.0. Will that mess up any database or corrupt my library? If not, I can give that a try. But figuring out which exact commit introduced this behavior will be difficult.

Todays build with https://github.com/mixxxdj/mixxx/pull/1566 merged still has the buggy behavior.

mixxx-2.0.0-rc2-1.12-git5758-release-macintel64.dmg 28-Dec-2015 11:24
is latest 2.0 build
→ DOES NOT HAVE THIS BUG (but also does not have
Tango skin)

mixxx-2.1.0-beta1-2.1-git6460-release-macintel64.dmg 31-Dec-2017 10:34
is the earliest 2.1 build
→ DOES HAVE BUG

Iirc in between there was no build infrastructure :/

[Be (be.ing)]

Ben, if you want to debug this, I suggest using Git bisect to figure out which commit introduced the problem.

[Benis (beenisss)]

Thanks, I will have a look at that.

Foss, is this exclusive to the Tango skin in your experience? I can't get it to come up with any of the others. Also, if I switch to another skin then back to Tango, the problem goes away...

[Benis (beenisss)]

I tested the last available release of 2.0 with the Tango skin and didn't get the issue, but the first available release of 2.1 has it. Is that sufficient evidence that the issue was introduced from the beginning with 2.1? Obviously 2.0 didn't support HiDPI.

[Foss-4 (foss-4)]

Interesting:

Affected: Tango, Deere (100% reproducible)
Unaffected: LateNite, Shade

[Foss-4 (foss-4)]

Ben are you using a retina mac? I am running a vintage mac from 2011 with no retina display ;)

Wonder why Deere would be affected for me but not you.

[Benis (beenisss)]

I'm on a Retina mac, yeah.

Just retested this and unfortunately it has only served to complicate things. Deere and Shade are consistently fine for me. Somehow I managed to set the issue off on LateNight, then couldn't reproduce it after a handful of go-rounds, now I've managed it a second time and I don't know how I did it.

Fun! -_-

[Benis (beenisss)]

This is just weird.

On LateNight after triggering it a second time I did the following:

Track loaded in both decks.
Deck 1 was playing (with choppy waveform), deck 2 was not.
Ejected deck 2, issue stopped.
Reloaded deck 2, still no issue.
Played deck 2, still no issue.
Stopped deck 2, issue comes back.
Played deck 2, issue goes away again.
Stopped deck 2, issue comes back again.
Reset track position of deck 2 by right-clicking Cue, issue goes away again.
Manually drag track position of deck 2, issue comes back again.

I can consistently reproduce everything above except for triggering the issue in the first place...

[Benis (beenisss)]

The CPU spikes still happen with the waveform off and with the same intensity, for the record. You can still see the effect on the track time counters, though it's more subtle.

Free screenshot of CPU spikes attached. The bit in the middle is where I switched the focus to another app.

Tbh this is beyond my ability level to investigate properly so I'm gonna need some pointers, otherwise it would make more sense to leave it open for somebody else.

[Be (be.ing)]

I am deprioritizing this since 2.1 was released with the workaround of disabling inline editing of metadata in the track table by default.

[Be (be.ing)]

Is this fixed with Qt5?

[Benis (beenisss)]

I want to say yes.

I attached a screenshot a couple of messages up of CPU spikes that coincided with the noticeable choppiness of the GUI. I've attached another one here from the beta that went out yesterday. Performance seems pretty sluggish overall - the GUI is pretty laggy and I'm barely getting 30fps if I have two busy waveforms on the go, but I genuinely think the spikes are gone rather than just being masked by the noise.

I'm a bit concerned about performance overall but IMO this particular bug is no longer a problem.

[Benis (beenisss)]

To clarify the above, there was also previously a pretty stark contrast between things before editing any metadata and after. As I said performance seems generally sluggish but there is no discernible difference between before and after editing metadata, which is another point in favor of saying it's gone with Qt5.

[Be (be.ing)]

Great, thanks for following up on this.

[Daniel Schürmann (daschuer)]

Today I was able could reproduce the issue with 2.1.6.
The update rate of the whole GUI was reduced to 300 ms or such.
The trigger was opening the preferences window.

[Daniel Schürmann (daschuer)]

On Ubuntu Trusty 64 bit.

[Be (be.ing)]

That's not the same as this bug.

[Swiftb0y (swiftb0y)]

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