Playback initialization problem, delay until playback starts, with SF3 soundfonts

• May 29, 2019 - 16:11
Reported version
P2 - Medium
S4 - Minor

I think this is new in V3.1.0, but since I installed V3.1.0, all attempts to execute older nightly builds execute V3.1.0 instead so I cannot check that.

Load the file Magyar Sandwich14c2r.mscz, set Musescore to resume the session on startup, set MuseScore_General as the default soundfont, and then close Musescore.

Open Musescore, select a rest and play - long pause (even though there are notes in other staves) then it plays. Close Musescore.

Open Musescore, select a measure with notes in it and play - long pause then it plays. Close Musescore.

Open Musescore, select a note - there is no sound, and again, no sound, keep at it and you get a sound.

Once a note has played, all is OK until the next time Musescore is opened.

The problem does not occur with my own soundfont nor with TimGM6mb.

Seems to fail on all my scores (but I do not normally use MuseScore_General, so it is not a problem for me).

Attachment Size
Magyar Sandwich14c2r.mscz 13.3 KB


This is a matter of the rather large SF3 default and HQ soundfonts which needs some time to get loaded and decrompressed into RAM. Nothing new with 3.1, was that way in 3.0.x already. Workaround is to use an SF2 variant of them

I have uninstalled 3.1.0 and re-installed 3.0.5 and the problem was still there.

It is not quite as simple as Jojo makes it sound. On my machine (Windows 7 x64) loading MuseScore_General in the synthesizer takes less than a second and the synthesizer is immediately ready to go but after the window is displayed when MuseScore starts up, it takes 17-18 seconds before the synthesizer is ready. During this period, processor usage is about 60%. With my own soundfont, processor usage drops to about 3% in less than a second, so this 17-18 seconds of high processor usage is loading/initializing the soundfont.

But as loading using the synthesizer takes less than 100% of the processor time for half a second, while background loading after startup takes more than 50% of the processor for 17 seconds this indicates a background task efficiency of about 10% (on Windows). Is it as bad on other systems?

That said, otherwise the startup of V3 is admirably fast.

Weird. I can reproduce the clicking a note and not getting a sound at first, but not anything else. I think it may be a soundfont issue rather than a midi rendering issue...

Priority P2 - Medium

Not sure whether we can exactly fix this but we can at least let a user know what happens when a soundfont is being loaded — for example, via a status bar message or some modal window in case user starts playback before that process is finished.