Terrible performance on Windows with a big score
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
I suspect now that MSVC release configuration is not a real Release with all the optimizations, because of #275281: "Init midi driver failed" when loading the program as well.
On August 2, this score works at expected with 8366ff1
And with this one (MSVC compilation), on August 4: e98043a
indeed, I observe too the playback is just an huge mess.
FWIW, no problem reading this score on mac with debug build.
It wasn't/isn't with MinGW builds either
In reply to It wasn't/isn't with MinGW… 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_DEBUGat lines 185-186 of CMakeLists.txt, here:https://github.com/musescore/MuseScore/blob/cc5bb5e4c6982f411247b8a033a…
with
/DNDEBUG /DQT_NO_DEBUGand maybe also add/DQT_NO_DEBUG_OUTPUTI tried to run a MSVC release compilation with these definitions and also by using
/Oxinstead of/O2, but unfortunately I still see this bug (the "NO_DEBUG" flags however make the debug output text disappear).In reply to On my machine, I have the… 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 I'm building x64… 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.
In reply to For that we'd also need a… by Jojo-Schmitz
I got ones from ABL's win64 package. Struggling with cmake, btw.
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.
MuseScore 64bit builds are on AppVeyor now - https://musescore.org/en/node/275540
The instruction has been updated respectively - https://musescore.org/en/handbook/developers-handbook/compilation/compi…
Created separate issue for still existing popping noise - #275544: Popping noise in MuseScore 64bit (Windows)
Automatically closed -- issue fixed for 2 weeks with no activity.