[Regression] Playback slow to engage

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

That doesn't crash here either

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.

There is a problem somewhere.

I would say related to this commit: [63d19c2]

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.

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?

I checked quickly (I was in a hurry), but there is a problem, surely.

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.

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.

Can someone who is able to reproduce the problem join in on IRC (#musescore channel on freenode) so we can try to figure this out more quickly?

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.

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?

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.

We've not yet covered the reported crash

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.

Could the fix for the delay be an info dialog that says "Wait..." or "Unpacking sf3 file" that displays as long as it takes to upack the file?

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.

"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?: https://drive.google.com/open?id=1t6hsqPmWyTn3H5iwyeQMYdtRIfWa6lDU

That way you don't have to revert to an earlier MuseScore version.

"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)

Yes, the only difference is that the SF2 version is uncompressed, so you don't have to wait for MuseScore to uncompress the SF3 version when it opens (which is what causes the delay you are experiencing).

Okay, I wasn't aware of this SF3 version vs. SF2 version.
I must have missed something or not read something about it before the release of the 2.2. Indeed, this unexpected and very inconvenient delay (my feeling) is fixed here by installing the Sf2 version.
Thanks Chris.

You can also get it from http://ftp.osuosl.org/pub/musescore/soundfont/MuseScore_General/MuseSco…, this always should be the latest official version and source for MuseScore_General.sf3

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.

OK, crashing in FluidS::Sample::decompressOggVorbis(char*, int) seems to make perfect sense in this context

"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?

Seems the most reasonable approach, at least for a quick fix for 2.2.1 and maybe even 2.3?

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).

See https://github.com/musescore/MuseScore/pull/3586 and/or https://github.com/musescore/MuseScore/pull/3587

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.

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).

>> Reason it takes longer than 2/1 is that the soundfont got bigger.
Thanks, that makes sense. I understand now.

See geetar's issue: #273634: Synthesizer: Hang then crash if you press "Load from score" at very beginning of session

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

There's no MDL in master, or is it?

Automatically closed -- issue fixed for 2 weeks with no activity.