optimize the CircularAverageMagnitudeDifference method

[barbeque-squared]

This is very similar to #619 but checks 1/16 instead of 1/32 of the (4096) samples. Especially when using six players, this gave me a significant improvement in performance.
The 16 was established mostly by a bit of trial and error but is ultimately just some arbitrary value.

WARNING: This isn't as tested as the optimization in 619. Unlike 619, this one also actually influences what ultimately gets detected. It could be that this has more impact on very low or very high frequencies which I cannot reach. If that is the case however, it's fairly trivial to split out how many samples it uses for every entry in the Correlation array. Perhaps it only really needs more samples for very high frequencies, but this gets looped so often, it's worth having the code do as little as possible.

[s09bQ5]

I'd prefer not to change the algorithm. How about parallelizing the analysis of different player's audio? It would be so easy if there was OpenMP for Pascal...

[barbeque-squared]

I don't think I'll be able to parallelize this. I also thought of it and it makes perfect sense, but I'm not that confident with Pascal yet. It shouldn't be impossible though.

I also realize the code I submitted might actually be wrong since it's still dividing by the number of all samples at the end.

Maybe it's possible to do something where we only have to compute stuff for the removed + new samples (instead of all samples). I'll figure out how many samples we get on average each loop, if it's very low that might be worth a try and wouldn't change the algorithm.

I'll give the removed/new one a try sometime soon, and if the gain is insignificant I'll just close this. At the end of the day, it's not that weird if pitch detection uses a measurable amount of CPU in a karaoke program.

[basisbit]

+1 for not changing the CAMDiff code either. I'd rather sacrifice a few CPU cycles than having the games song ratings change so that highscores are not comparable any more.
If you decide to do a "breaking change" anyways, might just as well do the change to Wavelet based audio analysis, as done in UltraStar Play - it is much more efficient, gives better result at lower sample sizes / latency and has vastly better noise resilience.

Edit: USDX works okay on an old Raspberry Pi (if opengl hardware acceleration over the OpenGL ES driver is enabled), thus I'd argue that there is no performance problem for rendering in singing scene.

[barbeque-squared]

Gonna close this because yeah, this isn't the problem. Once I figured out how to run the game at unlimited fps, it's still an improvement, but not significant.