[Regression] Playback slow to engage

• Mar 27, 2018 - 13:29
Reported version
S3 - Major

2.2 (Official release, not a nightly)

(Note (edited): The attached score was originally set up to play the "Yamaha Grand Piano" sound in a customised version of the previous soundfont—renamed "FluidR3Mono_GM2-312.sf2")

  1. If MuseScore is already open, close it.
  2. Open/reopen MuseScore and load the attached score (say).
  3. Press play.

Result: Playback very slow to engage if at all. Playback can be activated by clicking on a note while waiting! Once playback gets going, the problem seems to disappear for all scores.

  1. Close and reopen MuseScore.
  2. Open attached score.
  3. Open Synthesizer and press "Load from Score."

Result: Crash.

Attachment Size
joplin_maple_leaf_rag.mscz 38.89 KB


No problem here for steps 1.-3. (there is a slight delay though between pressing play and the start of the playback)
Steps 4.-6. lead to no sound at all.

I don't have any soundfont but the default one

Could the problem be something to do with the name of the previous soundfont? Previous to 2.2, I used a customised version of FluidR3, renamed to "FluidR3Mono_GM2-312.sf2".

The following operation also caused a crash with the above file (and others).

  1. Close and reopen MuseScore 2.2.
  2. Open attached score
  3. Open Synthesizer > Fluid, and try to delete "MuseScore_General.sf3".
Status (old) active needs info
Status active needs info

No issues with playback for me. When I press "Load from Score", I get no soundfont (and hence no sound) at all, which is understandable because I don't have a soundfont by the name of FluidR3Mono_GM2-312.sf2. But no crash, either. Also no soundfont, no sound, and no crash, if I remove the default soundfont from the list (after a restart).

Could be your customzied soundfont that is the problem.

I did not notice anything particular this morning. But not being able to reproduce the crash, I did a RevertToFactorySettings. I should not have done it!
Now, even after a complete uninstallation and reinstallation, my official version is not usable. There is a big latency delay. For example, when I enter four quarter notes, I begin to hear from the fourth. Same delay when starting playback.
And so, I observe this phenomenon with the commit mentioned above , and not with the previous one.

Status (old) active needs info
Status active needs info

Hmm, I just tried a Revert, and nothing special happened. Everything still works as described above. I'm on Windows 10. The commit you mention has to do with the naming/installation of the default soundfont. If I go to C:\Program Files (x86)\MuseScore 2\sound, I see two files: MuseScore_General.sf3 and MuseScore_General-license.md. Are you seeing anything different from this?

Since you mention a certain build where the problem first occurred, this suggests to me you are testing using a nightly build and not with the actual release? Could it be that the problem only has to do with people actually mixing and matching between the two and wouldn't affect clean installs? Again, I am unable to reproduce no matter I try. I do have a nightly build installed, but only one from after that particular change.

Status (old) active needs info
Status active needs info

Until there is enough information to allow a developer to reproduce the problem, please leave the status of an issue at "needs info" - that is the whole point. We need more information to learn how to reproduce the problem. Not that it really matters in this case because we know we need more information, but more as an FYI for future reference.

A theory: maybe people who are experiencing the problem have especially slow disk drives? My CPU is quite slow, but my drive - solid state - is pretty fast. It could be there is a lag loading / decompressing the soundfont on systems with slow drives.

In reply to by Marc Sabatella

Does the initial delay in sound production go away if you use the SF2 version of the default sounds rather than SF3?
1. Download the SF2 version here: https://drive.google.com/open?id=1t6hsqPmWyTn3H5iwyeQMYdtRIfWa6lDU
2. Extract the ZIP and copy MuseScore_General.sf2 to your MuseScore project folder's "SoundFonts" subfolder.
3. Load/create a project in MuseScore and go to View->Synthesizer.
4. Select "MuseScore_General.sf3" in the list and click "Delete". Optional: say the word "Delete" in a Cyberman voice.
5. Click "Add" and select "MuseScore_General.sf2".
6. Click "Set as Default".
7. Close and re-open MuseScore.

Is the delay still there?

Starting MuseScore by opening a score and as soon as possible starting play I see a 2 seconds delay and a slight peak in CPU usage, even with SSD and 8 cores.
Starting MuseScore, loading a score, drinking a coffee and then start playback: no delay at all.
Using an SF2 soundfont, no matter the size: no delay

Yes, I think a consensus is developing on IRC: this is the time it takes to initially load and decompress the soundfont. Takes a few seconds. So you only see a problem if you start MuseScore and immediately try to make sound. Wait even 5 seconds and all is well. Can others confirm?

Severity S2 - Critical S4 - Minor
Status (old) needs info active
Status needs info active

OK, I think we understand well enough now. It does appear to be the time it takes to decompress the soundfont when it is first loaded. Large soundfonts in SF2 format are not a problem, but SF3 requires uncompressing everything, and the new soundfont is larger than the old. Meaning the delay uncompressing the current default soundfont is more than it was with either the old default - and there is no such delay at all with uncompressed soundfonts.

Since the delay is only a few seconds when you first start MuseScore and then it's fine after that, this isn't as big a deal as it may have first appeared.

Title Playback slow to engage. Load from Score causes crash Playback slow to engage

True. Most likely that is an entirely separate problem, and critical indeed. If anyone is able to reproduce that, I'd encourage them to open a new issue, and keep this focused where it mostly has been, on the lag.

I guess the delay depends on your CPU speed, maybe drive speed. I have a slow CPU but a fast (solid state) disk and it's more like 4 seconds for me.

But the point is, you don't see the delay unless you try to enter notes or hit play immediately upon startup. If you wait those few seconds before pressing a button - which most people will likely do most of the time - there won't be any delay at all. I guess we'll see if this gets reported a lot. My guess is it won't be, but maybe I'm wrong.

After further testing, the delay disappears, as predicted, with MuseScore_General.sf2 as the soundfont. And if using the sf3 version, waiting up to 10 secs before pressing playback does reduce, if not eliminate the delay. It appears that the crashes documented above happened while the soundfont was still decompressing.

"So you only see a problem if you start MuseScore and immediately try to make sound. Wait even 5 seconds and all is well. Can others confirm?"
This is the problem noticed indeed. Unexpected to say the least when you were used to the immediate reactivity of previous versions, both to enter notes (so not only for playback), or to launch playback to check multiple pieces, files and tests! And my CPU is powerful though. Hope this will be improved quickly.
Meanwhile, I think I will go back to a 2.2 dev. of March 24, which "answers" to me at the quarter turn! More enjoyable use.
Here, higher status that "normal", no doubt.

"Why not just use the SF2 version of the SoundFont?"

Sorry of unknowledge, but this version does contain all the last improvements of the soundfont? (eg filters for guitar treble notes)

In reply to by [DELETED] 5

If it can be of any help, I can reproduce the crash only if I am quick enough in opening the Synthesizer and clicking the "Load from Score" button.
Attached you can find the log from address sanitizer, which apparently confirms that the crash is due to the fact that we are deleting the SFont object when we are in the middle of decompressing its samples.
If I wait a couple of seconds (so that the decompression has ended), it no more crashes.

Attachment Size
fluid_decompress_crash_log.txt 7.63 KB

In reply to by ABL

"which apparently confirms that the crash is due to the fact that we are deleting the SFont object when we are in the middle of decompressing its samples.
If I wait a couple of seconds (so that the decompression has ended), it no more crashes."

Would that warrant a QMutex to lock access to the object, and maybe spin on the lock if want to delete it, and only release the lock after decompressing finishes?

There are several problems here. 1. the crash, not good, but a quick fix is probably possible. 2. The fact that it can take a few second before score load and ability to play, without any UI feedback. This is less urgent and the price to pay for now for larger ogg samples. This is need a long term solution.

Regarding the crash,
The mutex is actually commented in Preset::loadSamples https://github.com/musescore/MuseScore/blob/2.2/fluid/sfont.cpp#L138
The comment makes sense since this function is called by Fluid::addSoundfount where the same mutex is also locked... Maybe we should just try to lock it, so we are sure to have it if the user wants to delete the soundfont (in this case, we should not try but wait, but that's already done: https://github.com/musescore/MuseScore/blob/2.2/fluid/fluid.cpp#L676)

"2. The fact that it can take a few second before score load and ability to play, without any UI feedback"

Could the playback button simply be greyed out while locked?

Graying out a button, a progress bar whatever, we can go crazy, but in order to do that we need a way to know when it's done in the UI thread. I don't think this is easy or there is safe way to do that in a couple of days (2.2.1 time frame).

https://github.com/musescore/MuseScore/pull/3586 is merged and should fix the crash for 2.2.1, 2.3 and master.
Unfortunately, we don't have a good solution yet for the slow playback at startup. It probably needs a big change.

Solutions I can think of include:

  • Decompress the SF3 once and for all on MuseScore first start. It would require a place to store the large SF2. SF3 is maybe not the right format for this. Sfark might be more suitable? Also, that will slow down the first startup.

  • Add some feedback when presets are loaded. As I said earlier, the difficulty is to track this process, follow its progress and report it to the UI.

In reply to by [DELETED] 5

SFZ maybe… SFArk is deprecated and “should not be used any more”, also hard to handle.

Perhaps a per-instrument cache of the decompressed waveforms?

On the other hand, SF3 is used precisely to make disc space requirements less… no idea how much this goes against that goal.

I'd recommend against saving the decompressed sample to the drive. Depending on user's cpu speed and drive (particularly SSD vs mechanical), CPU decompression speed may be faster than reading uncompressed from disk. Anyway people will complain about the extra disk usage.

I haven't looked at the code, but brainstorming some things that pop into my head, of varying difficulty:
1. speed up decompression by using as many decompression threads as CPU cores.
2. start with a very basic minimal soundfont/synth that can render while the bigger soundfont loads.
3. keep track of which instruments have been decompressed so far and allow those instruments which have decompressed already to use the soundfont, instead of waiting for all instruments to load first.

Sorry I'm a bit late to reply, but do we know what caused the regression in 2.2? Was it something to do with MIDI out, or is it maybe something to do with the new soundfont? The point is, it worked perfectly fine in 2.1, so something must've changed in 2.2. A start to a solution would be to understand what caused the problem in the first place (i.e. what change from 2.1 to 2.2 is responsible for the problem). If we know that, we can start looking into why that causes a problem.

Cause is totally known and understood, just read through the discussion above - it's about the time to uncompress the samples. Reason it takes longer than 2/1 is that the soundfont got bigger. Workaround for now if those extra few seconds are a concern is to install an already-uncompressed SF2 version of the soundfont as described above (or a different soundfont entirely).

Win 7/10. MS 2.2.1, 51b8386 (also present in latest 2.3 nightly)

Another example of a hang/crash:

  1. Open MS and load the attached score.
  2. Quickly open the synthesizer and press "Load from Score."

You will get a hang/crash if this is done quickly enough. If you have a "super-fast" system you may have difficulty reproducing the issue.

Attachment Size
drum_patterns.mscz 10.53 KB
Status active fixed
Regression No
Workaround No

Initial issue is not the case with current master. The issue for "fast clicking" was created.