Terrible performance on Windows with a big score

• Aug 17, 2018 - 22:18
Reported version
3.0
Type
Functional
Severity
S3 - Major
Status
closed
Project

Set Major because it is impossible to hear correct playback in the attached score in 3.0.
My laptop configuration is i7-6700HQ, 12Gb RAM and SSD.
Tested with self built MuseScore on OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (32-bit): 3.0.0, revision: 44304ca

Open the attached score and start playback.
Result: you hear popping noise and incredible mess starting at measure 14.

PS. We heard the same in 2.3 when I implemented the cache for the buffer. Btw, this score opened in 2.3.2 sounds great.

Attachment Size
2907471.mscz 110.34 KB

Comments

In reply to by Jojo-Schmitz

On my machine, I have the same result (i.e. I see the bug) for a MinGW debug build (32bit), while a MinGW 32bit release bit, as already said, does not show this bug.
Under Linux Mint 18.3 (same machine) I do not see the bug even in a debug build.
I think however that these MSVC builds are actually release builds; the only thing missing is maybe to substitute -DNDEBUG -DQT_NO_DEBUG at lines 185-186 of CMakeLists.txt, here:
https://github.com/musescore/MuseScore/blob/cc5bb5e4c6982f411247b8a033a…
with /DNDEBUG /DQT_NO_DEBUG and maybe also add /DQT_NO_DEBUG_OUTPUT

I tried to run a MSVC release compilation with these definitions and also by using /Ox instead of /O2, but unfortunately I still see this bug (the "NO_DEBUG" flags however make the debug output text disappear).

In reply to by ABL

I'm building x64 configuration to check whether the reason is 32bit compiler. I read few articles which state that 32bit compiler results in about twice slower runtime result than mingw 32 bit, but msvc 64bit compiler results in a bit faster results than both mingw32 and mingw64.

In reply to by Anatoly-os

For that we'd also need a lame_enc.dll for 64bit. Other than that: let's go for 64bit builds, like we already do for Linux and Mac, now that we can relatively easy.
We could even provide both, a 32bit MinGW and a 64bit MSVC build. Esp. if we can't get the MSVC 32bit build to perform.
Actually IMHO a better idea than to abandon MinGW.

Good news everyone! 64bit build is amaizingly rapid.
I'm preparing update for build instructions and different staff for building both 32 and 64 bit, but still. The reason is indeed not optimized 32-bit compiler.

Regarding this file, there are no lags or glitches, but popping noise still exists. It existed half a year ago in 3.0 when I fixed Mac Sound issue, so it doesn't relate to the optimization. It is more about specific changes in sound processing.