option to turn off on-the-fly waveform/bpm generation

[RAWRR]

This has spawned from an idea to ameliorate bug #1431168.

On some systems, generating waveform/bpm analysis data for the first time can be intensive enough to disturb playback in a set, and in my case my system has even locked up. As a safety feature, and because it is weird that you currently can't, it seems smart to have a way to turn off generation for un-analyzed tracks.

[Be (be.ing)]

What is it that really takes up resources? Is it waveform generation, beatgrid detection, or ReplayGain analysis? As ywwg said on bug #1431168, BPM and ReplayGain analysis are required for a lot of functions in Mixxx. If it is waveform generation that is really the issue, should the option be to just disable waveform generation but keep analyzing for beatgrid and ReplayGain?

[Be (be.ing)]

I forgot to mention key detection. How resource-intensive is that?

[Sean M. Pappalardo (pegasus-renegadetech)]

Once the above questions are answered (sorry, I'm not familiar enough with the code to answer them myself,) perhaps we should instead consider having the resource-intensive part automatically abort if it is determined the CPU load gets too high.

To gather more data on this, RAWRR, on the affected system, are you able to build Mixxx from source with the profiling=1 flag? Then run Mixxx and make it stutter or hang the system, then attach the gmon.out file that got created to this bug.

[Be (be.ing)]

Having the resource-intensive part automatically abort if CPU usage gets too high sounds like it may be a reasonable way to handle this during playback. However, users would likely wonder why they don't see analysis data for the track they just loaded, especially if other tracks have analysis data. An unobtrusive warning could be displayed somehow, but taking the time to read and understand the warning while DJing does not seem like a good idea. If this is implemented, it must only be implemented when adding tracks to a deck and not for the bulk library scanner.

[Be (be.ing)]

Depending on what is actually taking so much resources, it may be a good idea to integrate the less resource intensive analyses into the library scanner.

[Owen Williams (ywwg)]

be aware the profiling doesn't really address the issues we have with lock contention, so you might get underruns even though the CPU never hits 100% on a core.

[Daniel Schürmann (daschuer)]

> perhaps we should instead consider having the resource-intensive part automatically abort if it is determined the CPU load gets too high.

That should be normally the job of the OS scheduler. But of cause, we can make mistakes that stops the OS from doing its job best.
I hope we have already found them since Mixxx 1.11 and if not ... ther is still some work to do. Any profiling data will help.

[RAWRR (rawrr)]

"What is it that really takes up resources?"

For me it is almost definitely the waveform generation. The lag or hang, observing probably hundreds of tracks, lasts *exactly* as long as it takes to generate the form in the GUI. The lag or even just the observed CPU spike is over immediately as the waveform is completed.

Be's #4 comments all are appropriate and observant; I think the fix is either to display "waveform data not yet generated" in the waveform window, or since that seems awkward and weak, just leave it blank. I wish there was a fallback generator like VGA mode is for when your OS doesn't have video drivers, something crude but immediately functional, but that is probably too much work.

"are you able to build Mixxx from source with the profiling=1 flag? Then run Mixxx and make it stutter or hang the system, then attach the gmon.out file that got created to this bug."

Guys, like a pathetic loser I still have no build environment and know next to nothing about setting one up. Pointing me to a quick guide for Linux will be super helpful. It's high time I just got it over with. I've tried code:blocks and codelite in the past, and am not interested in Eclipse, but always had some kind of issues. I'd be open to something simpler too, like cmake :P

[RAWRR (rawrr)]

And as per Daniel's suggestion in https://bugs.launchpad.net/mixxx/+bug/1431168/comments/9 , I think it would be appropriate, if possible, to be able to selectively turn off waveform generation specifically, as distinct from BPM/replaygain. I don't know how intensive it is for the BPM engine/analyzer/thing to generate that data though...

[Be (be.ing)]

gprof clearly shows that ReplayGain analysis and waveform generation are the big resource users. Thus, I think BPM and key detection should be done when scanning the library whereas ReplayGain and waveform generation should stay in the separate analysis step.

[Swiftb0y (swiftb0y)]

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