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

[mixxxbot]

Reported by: rawrr
Date: 2015-03-12T23:16:34Z
Status: New
Importance: Wishlist
Launchpad Issue: lp1431616
Tags: analyzer, waveform
Attachments: [gprof output for opening Mixxx and analyzing a new FLAC file](https://bugs.launchpad.net/bugs/1431616/+attachment/4354935/+files/gprof output for opening Mixxx and analyzing a new FLAC file)

---

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

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.

[mixxxbot]

Commented by: Be-ing
Date: 2015-03-13T14:12:20Z

---

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?

[mixxxbot]

Commented by: Be-ing
Date: 2015-03-13T14:50:00Z

---

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

[mixxxbot]

Commented by: Pegasus-RPG
Date: 2015-03-13T15:25:00Z

---

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.

[mixxxbot]

Commented by: Be-ing
Date: 2015-03-13T15:48:58Z

---

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.

[mixxxbot]

Commented by: Be-ing
Date: 2015-03-13T15:52:25Z

---

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.

[mixxxbot]

Commented by: ywwg
Date: 2015-03-13T17:14:49Z

---

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.

[mixxxbot]

Commented by: daschuer
Date: 2015-03-13T18:58:08Z

---

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.

[mixxxbot]

Commented by: rawrr
Date: 2015-03-14T11:20:27Z

---

"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 mixxxdj/mixxx#4913 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

[mixxxbot]

Commented by: rawrr
Date: 2015-03-14T11:37:31Z

---

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...

[mixxxbot]

Commented by: Be-ing
Date: 2015-03-24T21:38:00Z
Attachments: [gprof output for opening Mixxx and analyzing a new FLAC file](https://bugs.launchpad.net/mixxx/+bug/1431616/+attachment/4354935/+files/gprof output for opening Mixxx and analyzing a new FLAC file)

---

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.