Reflect analyser finished by waveform overview

Hi Daniel,

All analysers execute concurrently (the analyser queue decodes the song in
chunks and runs every analyzer on each chunk) so the ordering of
AnalyserGain and AnalyserWaveform doesn't matter.

I think it may be best to re-enable the progress bar behavior and tie it to
an 'analysis progress' stored in the TrackPointer.

On Wed, Jul 4, 2012 at 4:08 PM, Daniel Schürmann <<email address hidden>
> wrote:

> ** Changed in: mixxx
> Assignee: (unassigned) => Daniel Schürmann (daschuer)
>
> ** Changed in: mixxx
> Status: New => In Progress
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1008721
>
> Title:
> AnalyserGain before AnalyserWaveform
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1008721/+subscriptions
>

All analyser task are processed in parallel.
The waveform overview is updated instantly, the replay gain is processed after all analyser are finished.

I have prepared a solution where the overview is updated 10% slower. The last 10% are updated after the replay rain is processed.

For me the bug is a regression from 1.10 so I would like to have it in 1.11.

Hi RJ,

an analysis progress in the TrackPointer will suffer the same problem.
We will have a smooth progress during the analysis process() and a skip at the end because of finalise().
In the trunk version there is nearly no process of the waveform overview in finalise().
The patch forces it to 10%

Hmm.. I'm not sure I understand. The behavior in 1.10 and 1.11 are the
same. AnalyserGain does not take effect until the analysis of the track is
completely finished (in finalize).

I think that the best we can do is let the user know that there is an
active analysis running and that could be accomplished by an actual
progress bar like in 1.10. It's similar to Bug #840860
The other option is to not change the gain at all for a currently loaded
track but then the user won't get the benefit of the replaygain calculation
until they load it a second time.

On Wed, Jul 4, 2012 at 4:58 PM, Daniel Schürmann <<email address hidden>
> wrote:

> Hi RJ,
>
> an analysis progress in the TrackPointer will suffer the same problem.
> We will have a smooth progress during the analysis process() and a skip at
> the end because of finalise().
> In the trunk version there is nearly no process of the waveform overview
> in finalise().
> The patch forces it to 10%
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1008721
>
> Title:
> AnalyserGain before AnalyserWaveform
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1008721/+subscriptions
>

OK I have retested 1.10.1, and you are right, the behavior is the same. I just haven't notice the problem in 1.10 until now.

Let me explain:
Some of my tracks have a calculates replay gain and some not. I don't keep track of that.
For my feeling the overview waveform takes the part of an analysis progress bar of a loaded track.
Assuming the analysis has entirely finished when the waveform is entirely drawn,
I have pressed play and heard a volume that is above what I had expected.
After some seconds it drops to normal due the actual finishing of finalize().

With the patch "analysis finished" is reported when analysis is actual finished.

An ADDITIONAL action would be not to change replay gain for PLAYING tracks.
This will fit perfectly to my patch because if the user starts the deck before replay gain analysis has finished he did not face a volume drop and if he starts later the replay gain is adopted. The user can clearly see by the progress the waveform overview waveform what will happen. With this we will get also rid of the reload meta data warning.

I have added my suggestions from #5 to a combined patch at Bug #84060.

Note the bug Daniel is referencing is from post #6 is #840860

Finally committed the patch from Bug #840860.

RE: Waveform changes I ended up leaving out some of the AnalyserQueue changes -- particularly the part with the semaphore because it causes priority inversion with the main thread. Basically the analyser cannot make any progress until the main thread reacts to it. It seemed like added the 60ms buffering of progress updates was enough to majorly cut down on the signal noise and WOverview redraws.

RE: Eliminating frees of Waveform objects, I removed that as well. The main reason was that it doesn't really save many memory allocations since the initially created Waveform objects are pretty small (no data is stored in them so its just a handful of pointers). Inflating the protobuf when reading the waveform from file takes tons of memory so the savings are really small compared to that.

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