[MU4 Issue] UI response slow when using Muse Sounds

[henkdegroot]

Describe the bug
See screen recordings. The same score being used.
First one with all instruments set to MS Basic, the response of selecting an item is instant.
Second one with all instruments set to Muse Sound, the response of selecting an item is very slow.
Difficult to see in the recording, but when the cursor stops moving I have clicked the object.

To Reproduce
Steps to reproduce the behavior:
Test with the attached scores

Expected behavior
Response of MuseScore should not be much different just because a different sound system is used.

Screenshots
If applicable, add screenshots to help explain your problem.

Screenrecording with MS Basic:

Screenrecording with Muse Sounds:

MuseScore files (renamed to .zip to allow upload):
Jingle_Bells_-_for_Brass_Band-MuseSounds.zip

Jingle_Bells_-_for_Brass_Band.zip

Platform information

• OS: Windows 10
• CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz 2.60 GHz
• Memory: 12 GB
• Disk: Samsung SSD 850 EVO 500 GB

Additional context
Add any other context about the problem here.

[MoritzBrueckner]

I'm having the same issue, using Windows 10 on an Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz with 16 GB RAM, the sounds are located on a Samsung SSD 860 EVO 1TB.

The problem does not only happen with text objects, but with all items in general. Selecting different items in the same bar works just fine, it only happens when selecting items in other bars or extending the selected range by at least two bars.

In case you cannot reproduce this, here is a screenshot from the profiler:

Please note that although the slowest function takes about 200 ms per call, the experienced lag is much slower than that (as you can see in @ henkdegroot's screencast above). During the lag, all CPU cores quickly jump to 100% utilization.

[bobjp]

I also have the same issue. Two different computers. Both with i5 CPU's and SSD's. One with 8 GB ram and the other with 16 GB Windows 10, version 22H2.
Select anything while using Basic sounds and response time is fine. Select anything while using Muse Sounds and there can be an up to two second delay. Staff objects or music notes.

[Tantacrul]

@bobjp @MoritzBrueckner & @henkdegroot:

Can you all check this build, which has a lot of performance improvements for Windows: https://github.com/musescore/MuseScore/suites/9417801459/artifacts/444885402

It would be massively helpful to get feedback on how much improved the situation is with this build.

[MoritzBrueckner]

Hi, the lags are still happening for me unfortunately, which I didn't expect since in the very similar #14379 the same build seems to have mostly fixed the CPU spikes. If I had to make an uneducated guess I would assume that it's caused by waiting for the MuseSampler, I'm not sure if changes to that would be reflected in MuseScore builds since it's updated in MuseHub?

I attached VS to the running Musescore process to maybe get more insight, I don't really have the time and disk space for the dependencies right now to build MuseScore myself. Unfortunately there is no CPU data available for the duration of the CPU spikes (There is no data in the current set of filters) but only shortly after attaching to the process. During that time, musesamplercorelib.dll seems to take most of the time, but since I don't have debugging symbols available and no data during the spikes it's probably not that helpful:

After selecting a different note but not non-sounding elements, the following is printed to the VS console (note the timestamps):

14:22:02.028 | INFO  | 9700 | MuseSamplerWrapper | handleAuditionEvents: START AUDITION NOTE
14:22:02.509 | INFO  | 9700 | MuseSamplerWrapper | handleAuditionEvents: STOP AUDITION NOTE

Perhaps related to this issue: #14383 (for me the lag also happens with non-sounding elements though).

Thanks for your work, please let me know if I can help with something :)

[Tantacrul]

OK, my mistake. It seems I had the wrong version open when I took that screenshot last time.

[henkdegroot]

It would be massively helpful to get feedback on how much improved the situation is with this build.

Not seeing any difference on my system when using this build.

[bobjp]

No improvement on my systems. Delay selecting anything in a score. Playback is now a bit garbled. Even with buffer set to 4096. Basic sounds work fine.

[Tantacrul]

Yeah, we've determined our performance improvements help a lot with playback but the UI problem is different. We have a pretty good idea why. We'll get back to you.

Thanks so much for testing!

[gampnico]

This issue occurs in the 4.0.1 release for Linux under specific conditions:

• If no objects are selected, selecting any note, entire measure, or dynamic marking causes a delay between the object being clicked and the object appearing selected and playing a sound - deselecting an object and selecting another causes the same delay. This also happens for MSBasic instruments whilst MuseSounds is the active profile.
• If a notation object is already selected, the delay doesn't occur when selecting another notation object.
• If selecting a rest (not the whole measure), the delay doesn't occur.
• If the score was recently opened, the delay is far greater (3+ seconds).

System: Ubuntu 20.04, SSD, 16GB RAM, i5 3.5GHz
MuseScore: AppImage, v4.0.1.230121751, rev. 9b70a8c, I/O buffer 4096
Profiler Screenshots:

[DmitryArefiev]

@henkdegroot Please try it again. There were some performance optimizations previously, and the last one in #22595

https://github.com/musescore/MuseScore/actions/runs/8849899936

[henkdegroot]

@DmitryArefiev it does seem to work a lot better. Also tested in 4.3.0. Excellent work.

[DmitryArefiev]

@henkdegroot Glad to hear. Thanks for testing! Kudos to @RomanPudashkin