Sound is having serious stutters and issues during Playback.

• Apr 4, 2018 - 03:53

So ive tried multiple methods of fixing sound in musescore, INCLUDING A FACTORY RESET, and sound device tweaks, but cannot solve a serious playback issue.
It only happens after two measures of playback, and causes an awful sound of piano stutter when i play back.
Rendering helps, but not when your writing.
Any ideas on what i can try?


The way I see it is one of these options.
1. You have too many programs running.
2. Your score is unfortunately corrupted.
3. You have applied too many SoundFonts to your score.

It would also help to know which platform you are using. (e. g. Chrome, Linux)

I am having serious stutter problems in 2.2.1; all the kinds of pianos stutter. Brand-new score, single-line (not a million parts). I am not running any unusual number of tasks -- Activity Monitor (Mac) shows the machine mainly idle. I cannot get a decent performance of a single part.

In reply to by BSG

I've debugged this further -- it is the echo/reverb -- by adjusting the "wet/dry" in the synth dryer (as it were), I can ameliorate it. But how will I know what my music will sound like online? Will it stutter? What should the nominal settings of the synthesizer effect panel be? I don't want to "reset everything in the app" to find out?

In reply to by BSG

If by "old sounds" you mean the old FluidR3 soundfont, and if by "stay" you mean, upon posting to, the answer is, they will if you first install FluidR3 as your default soundfont and then also use the "Upload score audio" button when saving online.

But it sounds like you really just need to fix your reverb settings. Here's a pic of the settings on my system, which should be the defaults:

2018-04-16 (1).png

In reply to by BSG

Your image doesn't show the soundfont. You need to click on the Fluid tab to tell us what soundfont you have loaded.

Somehow, the problem you are experiencing seems unique to something about your scores or your system.
So it would also help if you uploaded a sample score that demonstrates the problem on your system. You might also think about what other changes you might have made to your system recently.

In reply to by BSG

Fluid_R3 was the old soundfont. So if you have truly updated to 2.2.1, you must have previously customized something about your synth settings or it would have updated automatically. To get the proper new default soundfont, delete that one and hit Add to add MuseScore_General, if desired.

In reply to by BSG

Indeed. I hope you are able to keep doing tests on your system to see if you can isolate what the trigger seems to be. Unfortunately, since no one else experiences this, there is little anyone can do to help figure out what is going on with your system.

In reply to by BSG

I rebooted and haven't had trouble since. I suppose for some (not obvious) reason it was struggling for wired buffer space or similar; I'll let you know if it recurs, but, otherwise, "reboot Mac" should be added to the folk wisdom for "stuttering".

In reply to by BSG

Cancel that "haven't had a problem since." It has happened a few times. Each time, I was able to identify a process or a group of processes (generally browser sub-processes) whose memory consumption I thought excessive and kill or otherwise throttle them, and the problem got better. But this never happened with 2.1; there is something different about its memory demands or usage patterns that has more sensitized it to memory pressure.

For what it's worth, I upgraded to the latest Mac OS (High Sierra) and am still hearing bogus irreproducible artifacts, occasional clicks and pops like a scratchy old phonograph record on playback on all scores, that never happened before 2.2. --hold on-- I think I have reproducible one --- this is not the same thing thing; posting new report.

In reply to by Jm6stringer

I suspected sound hardware, too, but this happens with high-quality headphones, and "hi-fi" amplifier, both plugged into the headphone port (not bluetooth), and does not happen for other sound sources, e.g., mp3 in iTunes or YouTube (so it is not loose wires, although it sounds like erratic wiring). But it does not happen for other sound sources.

I haven't heard from any MacOS users on the thread.

In reply to by BSG

As far as I know, the website playback is simply playing an mp3 file. Both scores play fine for me and apparently several others, so this to me seems very strong evidence (if not quite actual proof) the problem is not in MuseScore but in something about your audio drivers and/or hardware. Another test, though, would be to simply download the audio from the website and play that using the same browser you are using to play the score online, and then maybe try other audio programs using that same file. if even one other program produces issues in that mp3, that pretty much clinches the deal.

BTW, when I say your audio drivers and hardware, I am not referring to the actual speakers or the cables connecting them. I'm talking about the hardware within your computer that converts from digital information to audio information - aka your "sound card". Either the sound card itself or its drivers seem to be flaky.

About crackling noises with MuseScore 2.2.1
- I used MuseScore 2.1.0 without any problem with a MacBook Pro (15', end of 2008), 2.4 GHz Intel Core 2 Duo, Mac OS 10.7.5 (Lion). However, when I moved to MuseScore 2.2.1, I had constant crackling noises during playback, except for the first one or two measures, with all instruments.
- I tried MuseScore 2.2.1 with a MacBook Pro (13', end of 2011), 2.8 GHz, Intel Core i7, Mac OS 10.12.6 (Sierra) and it morked fine, without any crackling noise.
- Therefore, the crackling noises appeared specific to the old MacBook Pro.
- I solved the problem with the old MacBook Pro (15', end of 2008) by linking MuseScore to Pianoteq through the new MIDI-output of MuseScore 2.2.1 and it worked fine.
- The MIDI-Output of MuseScore 2.2.1 is a big improvement. When composing and finely tuning the nuances of piano pieces, I used to export the score as a Midi file and then import it into Pianoteq. Now this can be done directly. Moreover, it gives the possibility of using MuseScore with numerous third party software instruments. Congratulations and thanks to the MuseScore team.

In reply to by hugues.bedouelle

This seems to correspond to my experience. I shouldn't have to obtain a different midi synthesis instrument. My MacBook Pro 15" is from 2012.

My observation this morning is to convey the following new bit. Let's limit ourselves to the local app cases, I'm willing to ignore anything I allegedly observed with the site -- may be different problems.

If I don't use MuseScore for a while, say, overnight, and come back and play a score, it stutters badly, all instruments. If I then immediately play the score again, it does not. I suspect it is not acquiring all the memory it needs prior to playing, or not ensuring its RAM availability in the way it should, in a way that differs with 2.2.1 and High Sierra. It is a large annoyance.

In reply to by BSG

I think you may well be correct about memory usage. When you compare against 2.1, are you using the same soundfont? The new default MuseScore_General.sf3 is considerably bigger, so it does take more memory, and in general, memory is managed by the operating system not by MuseScore, so if macOS is not giving MuseScore as much as it needs up front, then the "paging" that happens as it gradually gives MuseScore more could indeed lead to stutters. If you stick with the same soundfont, though, memory usage should be comparable to 2.1, although it's certainly possible other changes icnreased memory usage slightly. I don't suppose you still have 2.1 installed to do a side-by-side comparison? Not sure if that's possible on macOS (on Windows, one could use the portable app version for this).

If you are able to do the side by side comparison - same score, same soundfont, once using 2.1 then again using 2.2.1 and you still see a difference, next step would be to fire up some sort of utility (presumably macOS provides one) to monitor CPU and memory usage).

If you are not able to run them side by side but instead are comparing how 2.2.1 performs today to how 2.1 performed a few months ago, but are at least able to verify you are comparing using the exact same soundfont, then I think it very unlikely the difference in MuseScore is what is going on - I think it's the difference a few months made. In particular, some other software on your system - perhaps macOS itself, if you've updated recently - is probably hogging memory today in a way it wasn't a few months ago.

In any event, the likely solution seems to be, add more memory to your system (one from 6 years ago likely is skimpy by modern standards), or just rely on the fact that, as you've discovered, you can get MsueScore the memory it needs by doing a quick dry run first.

In reply to by Marc Sabatella

Not ready to buy a new Mac (I don't think memory can be extended in a MBP). How do I reliably set the sound-font, and be certain which one it is using for an extant score? I see two (sf3 and Gen) in "Synthesizer", but I'm not sure about the things I just asked. I might have 2.1 ....

I have 8gb of RAM. When this happens, I don't see massive memory pressure in Activity Monitor. I suspect it is not "asking for enough" in some way. I'm playing a medium-texture score, and AM reports that MS is using less than 500 MB, virtually nothing, and it is stuttering some.

In reply to by BSG

Easiest way to be sure which soundfont you are using is to only have one loaded. If you have two loaded the top is used by default but if you've used View / Mixer to deliberately choose sounds from the other, then you'd be using that as well or instead.

What soundfont were you using in 2.1? Do you remember? Is that soundfont still on your system - does it show as an option when you hit the "Add" button in the synthesizer window? If so, I'd recommend adding them and deleting all others from the Synthesizer window, and seeing if the problem persists. Be sure to hit "Set as Default" to make sure this sticks.

In reply to by Jm6stringer

I don't really understand the binding between soundfonts and scores. If I download a new soundfont, such as the one just mentioned, and move it to the top of the Synth panel, does that affect the score i am editing, or any other scores, and if not, when? Does the name of the soundfont(s) in use by a score get stored with it, and restored when the score is edited? How, in the mixer, can I tell which voices belong to which soundfonts? Are there names common between soundfonts? What happens then? Which soundfont(s) will the app page in when the app is started? When a score is opened?

In reply to by BSG

Re: binding between soundfonts and scores
A soundfont comprised of piano samples of a Bosendorfer grand will sound different from a soundfont made from samples of a Baldwin upright.

How, in the mixer, can I tell which voices belong to which soundfonts?

If you have more than one soundfont added to the Synthesizer, the instruments that appear in the Mixer's sound dropdown list are arranged according to the order in which the sound fonts are listed in the Synthesizer.
So... if you have MuseScore_General.sf3 listed first on the Fluid tab of the Synthesizer, those instruments will appear first as sounds available in the Mixer, followed by the next set of sounds belonging to any subsequent soundfont displayed in the Fluid tab of the Synthesizer.

Are there names common between soundfonts?

As an example, it could be that the word 'flute' might appear in the first soundfont and then, after scrolling through all the sounds contained in that soundfont, it may reappear as 'flute' again, but this time it refers to the flute sound from a subsequent soundfont displayed in the Fluid tab.
(Sometimes you can get lucky and one might be named 'Gemeinhart flute' and the other, simply, 'flute'.)

Which soundfont(s) will the app page in when the app is started? When a score is opened?

From the handbook link above:
"When you open MuseScore, the Synthesizer always assumes the current default settings. If you want a new default to apply at the next session, change the settings as desired, then press the Set as Default button."


Fortunately or unfortunately, "clicks pops dropouts High Sierra" finds a lot of other people encountering what seems to be a Mac problem. It only shows up cripplingly in MuseScore, though.

HALLELUJAH! I just updated (as prompted) to MacOS (High Si) 10.13.5 (it was a very difficult birth, btw), AND THIS PROBLEM SEEMS TO BE GONE. MuseScore plays a piano piece perfectly with no problem at all. MAC USERS TAKE NOTE! (See, I wasn't making it up!). : )

In reply to by BSG

Well, it still happens occasionally, but the situtation is still radically, 100 times, better than it was before 10.13.5, and usually "playing it again" (as though memory had to be paged in) "fixes" it. Damn, Macs are imperfect : (.

This is still a wretched problem. My observation of its amelioration was premature. I do have this bit to add, however. When I open a score and play it, stuttering is almost assured. But if I stop the playback and return to the beginning, stuttering will not commence until the point where I stopped. It is as though it is failing to bring stuff into memory until it gets to it. This really started with 2.2, and is intensely annoying (in effect, I have to pre-play sections of score in order to hear them without corruption).

In reply to by BSG

Hi, I just stumbled across this thread. I if it's any consolation , I have the same problem:
It has been like this since upgrading to 2.2-- I tried to downgrade to 2.1, but then it wouldn't read scores made in 2.2. I just upgraded to the latest release, 2.3, and there is no change in the problem.

I run heaps of audio software, write my own dsp algorithms, and this is the only piece of software on my computer that has this problem.
Your computer is not "too old"-- somehow the musescore software has been built with this problem since 2.2.

It needs to be ticketed and fixed.

In reply to by BSG

I have just downloaded (& down-graded to) 2.1 and it works fine! No stuttering or distortion during playback.

Versions 2.2 and 2.3 both display the same poor behaviour. So there is some difference between 2.1 and the later versions that should be amended.

I played the same score (very simple piano part) with the same preferences including same synth for all 3 versions, all on the same computer & OS of course, and only 2.1 works properly.

you can get it here:
(the.dmg file for a mac)

In reply to by flesh robot

I confirm this same result. I ran 2.1.0 out of the dmg file, two scores, first thing in the morning and not the slightest glitch. Same machine, same HighSierra patch level. This has to be tracked down and fixed; it is gutting my MuseScore experience, and @flesh\ robot confirms that I'm not crazy.

In reply to by BSG

We are still awaiting any sort of definitely comparison from those of you experiencing the problem between the soundfonts FluidR3 and MuseScore_General. You can either test both using 2.1 or 2.2.1 - or, preferably, 2.3. If one soundfont shows the problem and the other doesn't, we will have learned something. If both show the problem in 2.2.1 or 2.3 and neither show it in 2.1, we will have learned something else But since no one on the development team can reproduce this problem, we really need those of experiencing the problem to help in the effort to track the problem down.

Now that there are two confirmed cases with apparently similar symptoms (actually, that's not entirely clear, the description of the sound itself seems different), there is another extremely valuable thing you two could do to help: start comparing your systems, making a list of the hardware and installed software to see if you can find a common denominator - something common to both of your systems that most people would not have. Then we would have something to test - would we be able to reproduce the problem on a similarly-configured system.

Right now it was stuttering so bad(ly) that it halted in the middle of a stutter and I couldn't make it start playing again. I tried to quit the app, and that failed. I had to kill the app from Activity Monitor. I restarted the app and it worked averagely (average amount of stutter).

I switched back to 2.3, and it failed to fail; my dalliance with 2.1 must have scared it; I can't imagine what's going on, except that maybe 2.1 changed some artifact in the (user) MuseScore directories. I tried switching sound fonts; both appear in my "Fluid" Synth pane, and tried two long, yesterday-failing pieces with one and then the other in the upper position, and it made no difference; to make sure I wasn't being faked out, I created a new score with only a piano (which sounds very different between the two fonts), and my "just switch the order" gesture indeed switched them, but has not (20 min into this) yet produced a failure.

In reply to by BSG

Interesting! But really, aside from the selection of the soundfont, there is nothing 2.1 could have done to affect 2.3 or vice-versa. So the most likely scenario to me remains that it is some other program or device on your system triggering the problem. When the other program is running or device connected, somehow a resource conflict occurs that MuseScore cannot handle. And maybe in fact 2.2 and later are more susceptible to this, either because of the soundfont change of one of the relatively small changes to the synth itself.

So maybe an interesting thing to try would be to run the Mac equivalent of WIndows "Task Manager" to show the currently running processes, take a screenshot, then do the same again when the problem inevitably (I'm afraid) returns.

In reply to by Marc Sabatella

OK this is bizarre.
Installed FluidR3Mono_GM.sf3 into Soundfonts folder.
In ms 2.1, added it into the synth list and put it to the top of the list. Played back fine, as expected.
Quit 2.1, opened 2.3, added same font into the synth list and put it to the top of the list. Stuttering as usual.
Conclusion-- soundfont idea has no bearing.

Then, while the score was still playing, changed back to my other font. This cause Musescore to crash.
Re-launched Musescore 2.3, clicked yes to "do you want to restore?" dialogue, then played back previous score (it was automatically reloaded).

This only just occurred so am yet to see how long it will last.....
[30 seconds later]
OK just played it back again and the distortion is back, regardless of font used.

Indicates to me perhaps something to do with the interface between the OS and Musescore?

Model Name: MacBook Pro
Model Identifier: MacBookPro8,2
Processor Name: Intel Core i7
Processor Speed: 2.2 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Memory: 8 GB
Boot ROM Version: MBP81.0047.B2A
SMC Version (system): 1.69f3

System Version: OS X 10.8.5 (12F2560)
Kernel Version: Darwin 12.6.0
Boot Volume: OS10.8
Boot Mode: Normal

In reply to by BSG

This morning I tried playing a score in the MS 2.3 instance left running from yesterday. No stuttering. I verified that it really was 2.3, not just from the About dialog, but by testing for the unison-clipping fix. Usually, the first playing of a score in the morning stutters horribly. Running 2.1 yesterday changed something. Are there any internal parameters about audio-use, such as buffer sizes, that are stored in some "registry"-like place by which one run of MS can affect later runs?

In reply to by BSG

We don't use the registry, basically we just save preferences to an INI file. There are certainly various settings that could be affected by running different versions of MuseScore - see Edit / Preferences / I/O - but assuming you've got the same API and device selected (have you verified that?) there really is nothing else that would be remembered from one invocation of MuseScore to the next, much less one version to the next. So really, much as it might seem that installing 2.1 magically did something, I have to believe you'll find it is another red herring. The only thing that has made any sense since pretty much the day you reported this is that some other program or device on your system is causing a conflict. If you really want to get to the bottom this, I would put put your effort into investigating that.

In reply to by Marc Sabatella

I didn't even 'install' it; I ran it 'out of the dmg' (compressed file-system which is the Mac delivery vehicle). But it ran. Yet anon morning has broken, but 2.3 is not broken! Very confusing. Waiting for a new failure before I have anything else to say.

it's BAAAACK! and is a total annoyance. I am running no audio-aware apps at all except iTunes which is open 24/7 year round. I am running no out-of-the-ordinary apps. No bluetooth. Memory consumption 7 out of 8 GB, in "green" (happy) area according to Activity Monitor. No software/system changes since it was last good.

I guess this is it from now on, as we have no way to debug it.

It can't have anything to do with what else is running. If I haven't used MS for several hours, and I start to play an open score, it stutters and stumbles horribly. If I pause, and immediately (no interaction with anything else in the system) go back to the beginning and play from there, it is clean up the point where I stopped its playing. It therefore has to do with fixing, or paging, buffers into memory.

In reply to by BSG

Indeed, that seems plausible. But, what else is running can effect how much paging is required. Seems to me if it's worth spending as much time as you've spent on this, it's worth trying something that might actually help. If your before/after logs show a difference, thats a starting palce for investigstion right there. Vut even if not, it doesn't mean the experiment failed. We'd just need the handful of others who experience similar problems to do the same, then compare to see if there is any insight into what is going on for the systems with the problem that is not the case for the vast majority of users who don't see the problem. Because it could be the issue is a conflict with a program that is always running for you but perhaps not always active. Could also have to do with libraries or other resources installed by some other program on your system. Lots of thigns could be the unique trigger that exists for you and a small handful of others, but without this kind of info, we can't begin to guess.

In reply to by Marc Sabatella

OK I've just uploaded 5 text files.
These are a summary of active processes when my computer is on during 5 different states:

1 Processes-default.txt: when computer is on without any user applications running (except the Activity Monitor utility used to perform this analysis).
2 Processes-MS_2.1_idle.txt: after launching 2.1 (which plays scores correctly).
3 Processes-MS_2.1-playing.txt: 2.1 playing a file
4 Processes-MS_2.3_idle.txt: after quitting 2.1 and launching 2.3
5 Processes-MS_2.3-playing.txt: 2.3 playing same file but with the inherent stuttering

These different states have between 105 and 110 processes.
Here is a summary of the differences:

New processes- MS_2.1 launched with file open:
PID Process Name User CPU Real Mem Virtual Mem
19003 MuseScore tel 2.6 237.6 MB 2.88 GB
19005 printtool tel 0.0 10.4 MB 2.43 GB
19006 MIDIServer tel 0.0 2.6 MB 658.4 MB
19011 diskmanagementd root 0.1 11.3 MB 2.44 GB
19012 launchdadd root 0.0 7.3 MB 2.40 GB

New processes terminated when MS_2.1 playing opened file:
PID Process Name User CPU Real Mem Virtual Mem
19012 launchdadd root 0.0 7.3 MB 2.40 GB
19011 diskmanagementd root 0.1 11.3 MB 2.44 GB

New processes- MS_2.3 launched with file open:
PID Process Name User CPU Real Mem Virtual Mem
19005 printtool tel 0.0 10.5 MB 2.44 GB
19016 helpd tel 0.0 10.2 MB 2.44 GB
19017 MuseScore tel 5.1 255.3 MB 2.91 GB
19019 MIDIServer tel 0.0 2.5 MB 638.9 MB

None of the new processes are terminated when MS_2.3 plays a file. Maybe this is a clue?

Let me know if you want a sample of any of these processes in a particular stat and I'll provide it/them.

In reply to by flesh robot

It's been tolerable this morning. Next time it gets into stutter mode, I will do similar. I installed MacOS 10.13.6 a day ago, and it may be muddying the waters. A month ago, 10.13.5 had me thinking it had fixed the problem, for a whiile ...(and my process lists probably differ from yours because you are running a very old OS).

In reply to by BSG

I just used activity monitor, which is a utility app that comes with os 10.x. Don't know if versions later than 10.8 have it but I assume they would. Just go to save and save as text while having nothing open except muse score. It's a long shot, especially given we have different OS x versions. but it's a starting point to have some sort of idea of a possible common source of the problem.

In reply to by Marc Sabatella

OK after much radio silence on this issue, I have upgraded to 2.3.2 and the problem persists. Here is a screen cast of the problem, attached as a zip file. Note I take out the reverb 45 seconds through the video and it still occurs. Changes in dynamics in the score have no effect on the stuttering/discontinuities.

Please note the exact same score plays back fine in version 2.1, but not 2.2 or 2.3 (same sound fonts and effects settings).

So update on this thread:
I have found the root of my issues, as i learned using the Spring update of Windows 10-
The error root likely resides in my sound driver, as it seems to be very picky about what programs can actually use it.
After SEVERAL months of trying out code, talking to my Game dev partners, and calling MSI and Microsoft twice,
and found a pointer.
If you are using a MIDI synthesizer (i.e i was using Coolsoft's Virtual Midi Synthesizer) for anything like PFA, FL Studio, or just to have fun with midi's on the internet, the Drivers can sometimes register as a sound output, and musescore will sometimes try to force throughput using it.

Basically, the fix was check where your sound is going in Preferences, and set the priority of Musescore to maximum.

This has nothing to do with other processes and everything with not having stuff in RAM in real time. This is still a royal pain. Sometimes when going to a score I haven't gone to recently (I always have many loaded),
it stutters horribly. Without fail, going back to the point where I had started playing from and re-playing plays without stutter, up to the point where I stopped, where stuttering restarts. If it had anything to do with other processes, replaying wouldn't have any effect.

In reply to by BSG

That's not true - other processes take RAM too, and it takes time for the OS to swap them out and MuseScore in, but once MuseScore is swapped in replaying would indeed go faster until another process gets swapped back too. If MuseScore is using more RAM than it did before for the same soundfont, that would show up in your monitor tool. Is that the case? Can you do an apples-to-apples comparison of memory usage using same soundfont, same score, same collection of processes running at once?

Here's a new data point (and this has absolutely nothing to do with which processes are running). If a piece of music has sectional repeats, say a short menuet with two repeated sections (marked with "repeat" barlines), i.e., "A A B B", the first time through either section stutters, but the second plays properly! That is, stutter, good, stutter, good. If this doesn't prove that it has nothing to do with other processes, I don't know what will. It has to do with something that MuseScore does the first time a measure is played back, and not done fast enough or soon enough or with enough stuff in main memory. It continues to be supremely annoying (2.3.2, latest Mac OS).

In reply to by BSG

It doesn't prove it, sorry - on the contrary, it supports the idea that other processes are involved. Caching is a truly wonderful thing that can often cause something to work better the second time than the first, and caching is something affected by other processes. MuseScore doesn't control how much of its own process is in memory, that is something the OS handles, and it bases this in large part on what else is going on.

In reply to by Marc Sabatella

One would expect that if other processes were causing caching to fail, it would (a) not affect the first time (what would be cached?) and (b) manifest the second time, because what the first time did would be driven out of the cache by the competing processes. However, exactly the reverse is true. It is not the code or common data which is failing to be cached, because after the successful repeat of A, B fails right at the boundary.

I guess not enough people are hit by this, esp on the staff, so it's probably here to stay.

In reply to by BSG

I'm not talking about the cache "failing", I am saying that the first time you access the playback data for a given passage, it might need to be swapped in if the OS had previously chosen to swap those pages out due to the demands of another process, and this swapping on first access is almost certainly the cause of the stutters. Once those pages have been swapped in (and possibly further cached), subsequent accesses will be much faster and hence glitch-free. So what you are describing is 100% consistent with the idea that some other process has forced the relevant pages to be swapped out, and this would completely explain why access is glitchy the first time but better the second time.

In reply to by mike320

I am not aware of any way to force an operating to do anything in particular regarding page swapping, although probably there are system calls provided by some OS's to at least "request" some sort of priority. It's tricky, though, because the data structures involved aren't necessarily all laid out consecutively in memory.

Here's an interesting experiment that just occurred to me: do you see a difference depending on whether you recently made an edit to your score? The playback data is mostly pre-computed before playback begins, and this happens any time you've made an edit t your score that requires regenerating playback data. So if you've recently made an edit, at least some of the data is more likely to still be memory as it was just recalculated. The longer it has been since any edit or previous playback, the greater the likelihood the OS will swap those pages out.

In reply to by Marc Sabatella

(I maintained the paged virtual memory system of a major OS some years ago). Why on earth should the OS keep the playback data for MuseScore in main memory if I haven't used it for a while? And anyway, it seems that if I download an mscz from the site, the very first time I play it, it stutters. So there shouldn't be any playback data savagely purged from main memory by ravenous memory hogs. Indeed, as @mike320 says, it should touch the "stuff" first (no, I don't know "how much of the score.").

What's more, you'd think that if I had ravenous runaway rogue processes, I'd see spikes and huge percents (memory and/or CPU) in Activity Monitor, and I'd seem SOME performance problems in SOME other applications. The problem, I think, is that MuseScore, in some circumstances, can't produce new playback data in memory fast enough to output it in real-time, at least on this 6-year old Mac, but once it has touched it and paged it in, it plays fine, even many seconds later. New Macs are very expensive.

In reply to by BSG

Exactly - if you haven't used the memory in a while, it is indeed likely that the OS will have swapped it out to make room for requests by other processes, which is why it is quite to be expected that the first attempt to playback after a period of inactivity might be glitchy, and why the first playback of a repeated passage is also likely to be more glitchy than the second.

I didn't say you had ravenous rogue processes, I am simply observing that OS's don't generally swap pages out of memory without reason - without incoming requests from other processes. They don't have to be "runaway" or "rogue" to have an impact - they just need to be something that is happening on your system but not on the systems of the people who don't have this problem.

Again, we don't produce most of playback in real-time - it is precalculated in part for this very reason. Only minimal processing needs to happen during the playback phase itself. But sure, it definitely seems like the OS is having trouble keeping up with the memory requests of even these minimal real-time demands, on some small subset of systems. So understanding why the OS seems capable of keeping up for most people but not for you still seems the most relevant thing to try to understand.

In reply to by mike320

I have also seen this today again and realised I also experience this, albeit very rarely, on Windows 7 32 bit and an old (probably 8-9 years) laptop with an Intel Core2Duo @ 2.0 GHz. I never paid much attention to it, since it is a very old and slow computer.

In reply to by Marc Sabatella

Yes, I too see it very occasionally, no more with a current version than any previous version, and in exactly the situations that make it quite obvious it is a matter of the OS swapping in the process on demand. Which is to say, it happens no more for MuseScore than for any other program on my system that sometimes it is slow to respond to an action after a period of inactivity in that window. This much is normal, but what BSG describes seems to go way beyond that.

In reply to by Marc Sabatella

it just happened again with a score I had loaded that I hadn't looked at for a couple of hours. I am not an expert on MacOS virtual memory, but if it's like many other paging systems, memory is managed in pages, regardless of their association with processes. And, indeed, once it starts playing in stutter mode, every single measure stutters, until there is a repeat. It's not like my response to the initial "start playing" is delayed, but every note of every measure is trashed. Unless I stop and go back to the beginning, even a minute later, and it's fine up to the point where it stopped. Why can't it just touch all the rendered playing data before starting to play it?

In reply to by BSG

That's definitely a possibility. The data structures are kind of "deep", with lists containing pointers to objects that themselves contain lists, pointers, etc. So it might be a bit of work to do a good job of walking the whole tree. Hopefully, if someone with the necessary coding skills is ever able to reproduce the problem, they could give it a shot and see how it works.

Do you still have an unanswered question? Please log in first to post your question.