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?

Comments

• Apr 4, 2018 - 05:11

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)

Reply

• Apr 16, 2018 - 20:01

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.

Reply

• Apr 16, 2018 - 20:13

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?

Reply

• Apr 16, 2018 - 20:39

If by "old sounds" you mean the old FluidR3 soundfont, and if by "stay" you mean, upon posting to musescore.com, 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

Reply

• Apr 16, 2018 - 21:26

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.

Reply

• Apr 25, 2018 - 18:59

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.

Reply

• May 14, 2018 - 01:22

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.

Reply

• May 17, 2018 - 01:30

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.

Reply

• May 17, 2018 - 02:54

When I play https://musescore.com/user/1831606/scores/810586 I get clicks, pops, stops/interruptions, etc. When I go to and play the YouTube backing this score, it plays smoothly. I have no idea what could possibly affect both your retransmission of a YouTube and my local app. I do know that it seriously affecting my enjoyment of the app and the site, and didn't happen until recently (months).

Reply

• May 17, 2018 - 17:21

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.

Reply

• May 20, 2018 - 20:48

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.

Reply

• May 24, 2018 - 14:14

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.

Reply

• May 24, 2018 - 16:32

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.

Reply

• May 24, 2018 - 16:38

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.

Reply

• May 24, 2018 - 17:46

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.

Reply

• May 24, 2018 - 19:17

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?

Reply

• May 24, 2018 - 20:31

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.
See:
https://musescore.org/en/handbook/synthesizer#synth-settings
https://musescore.org/en/handbook/synthesizer#fluid

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

Regards.

Reply

• Jun 2, 2018 - 15:53

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.

Reply

• Jun 12, 2018 - 18:30

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

Reply

• Jul 1, 2018 - 23:12

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

Reply

• Jul 2, 2018 - 11:38

See https://musescore.org/en/download#older-versions -> https://ftp.osuosl.org/pub/musescore/releases/, pick your version and there the dmg file.

All 2.x versions are fully compatible to one another (with very few and minor exceptions, like the Play Repeats property of jumps introduced in 2.2 gets ignores in 2.1 and older, or crescendo lines introduced in 2.1 getting shown as hairpins in 2.0.x)

Reply

• Jul 3, 2018 - 02:40

Hi, I just stumbled across this thread. I if it's any consolation , I have the same problem:
https://musescore.org/en/node/273832
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.

Reply

• Jul 3, 2018 - 11:55

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: https://ftp.osuosl.org/pub/musescore/releases/MuseScore-2.1/
(the.dmg file for a mac)

Reply

• Jul 3, 2018 - 12:17

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.

Reply

• Jul 3, 2018 - 16:15

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.

Reply

• Jul 3, 2018 - 02:47

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

Reply

• Jul 3, 2018 - 17:05

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.

Reply

• Jul 3, 2018 - 17:14

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.

Reply

• Jul 4, 2018 - 01:07

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).
SCORE PLAYED BACK WITHOUT DISTORTION!!

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

Reply

• Jul 4, 2018 - 12:32

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?

Reply

• Jul 4, 2018 - 19:46

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.

Reply

• Jul 9, 2018 - 01:42

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.

Reply

• Jul 9, 2018 - 21:10

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.

Reply

• Jul 9, 2018 - 21:46

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.

Reply

• Jul 10, 2018 - 13:12

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.

Attachment Size
Processes-default.txt 9.16 KB
Processes-MS_2.1_idle.txt 9.58 KB
Processes-MS_2.1-playing.txt 9.41 KB
Processes-MS_2.3_idle.txt 9.5 KB
Processes-MS_2.3-playing.txt 9.5 KB

Reply

• Jul 11, 2018 - 13:03

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

Reply

• Jul 12, 2018 - 13:31

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.

Reply

• Aug 26, 2018 - 10:35

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

Attachment Size
Musescore2.3.2playback-screencast.mp4_.zip 2.71 MB

Reply

• Jul 17, 2018 - 18:56

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.

Reply

• Aug 4, 2018 - 21:34

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.

Reply

• Aug 4, 2018 - 23:34

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?

Reply

• Nov 5, 2018 - 14:18

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

Reply

• Nov 5, 2018 - 18:08

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.

Reply

• Nov 5, 2018 - 18:17

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.

Reply

• Nov 5, 2018 - 18:40

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.

Reply

• Nov 5, 2018 - 18:48

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.

Reply

• Nov 5, 2018 - 18:50

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

Reply

• Nov 5, 2018 - 18:56

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.

Reply

• Nov 5, 2018 - 21:10

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.

Reply

• Nov 5, 2018 - 21:18

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.

Reply

• Nov 5, 2018 - 21:36

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?

Reply

• Nov 5, 2018 - 21:52

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.

Reply

• Nov 28, 2018 - 15:41

I downloaded the MuseScore3 Beta, then chose a random recent score from those reporting on my dashboard, downloaded it and opened it in MuseScore3 Beta, and it repeatably plays clean "as a whistle" (or, more accurately, piano). I immediately then opened the same score in MS2 and it is hashed to hell by stuttering (as is always the case the first time a score is played). Something changed radically (for the better). So far so good!

Reply

• Nov 29, 2018 - 14:03

Nope, MS3 is not free of the same problem, although it seems marginally better. After the computer being dormant all night, I came back to ms3 and played the score I had been working on (the only in MS3), and the first time through each passage, there was a lot of annoying stuttering. Clearly, over the night (and the hours surrounding it), it had been paged out of main memory, and can't page itself back in enough fast enough while playing, having nothing to do with other processes: It is totally reasonable that an app and its data be paged out after not being used for several hours. Maybe my 6-year old Mac is just too slow, although it sure would help if it would touch the buffers it's going to need before starting playing.

Twice during a stutter it got stuck on the notes it was playing. New Macs are very expensive.

Reply

• Nov 29, 2018 - 14:32

Running Mac/Mojave (this problem is known to be Mac-specific). No - why would I ever shut it off such that reboot is required, short of an OS crash/hangup (every few weeks)? Computers (even my 6-year old one) have advanced beyond the state where they have to lose memory state to shut down power consumption; the Mac "goes to sleep" if allowed to if not used. Most apps even checkpoint enough (Aquamacs Emacs is one that does not) to survive even a reboot of the OS. The only effect I don't "understand" is why MS3 played correctly the first time I used it, playing a score it had never loaded (and thus had to render and page in at the same time).

Stuttering or not, I consider MS3 a huge boon (for the Piano Roll Editor usability alone, with the correctly-functioning "rewind button" a close second). It crashes a lot, too, but I assume that will get better with time.

Reply

• Jul 16, 2019 - 21:21

I'm having this problem too. Seems to have persisted to Musescore 3. This didn't always happen for me though. Some notes:
According to activity monitor memory is in the green: only half used.
Occurred in headphones as well, but not as much.

Reply

• Jul 17, 2019 - 18:36

I have some observations about some things brought up in this conversation. All based on personal experience. ALL computers store temporary data about what is going on with it. Everything you do is remembered somehow, somewhere. The longer your computer is on, the more data that is stored. Period. It may "page out", but it never goes away as long as your computer is on. Your computer is never "dormant". Even if you leave it on overnight without using it, processes are still active. Your computer is always searching for all kinds of updates, checking for viruses, receiving messages, all manner of internal things, and more. It keeps an extensive log of everything. Some of this data is stored permanently. Lots of it is stored in temp folders. Putting the computer in sleep mode is not a complete answer because processes have to be running to wake the computer up. Eventually temp folders get huge. Conflicts can arise. It happens. There is software that can empty temp folders. Another way that helps is a restart. Macs seem to be particularly prone to this problem. I have dealt with so many Macs that are left on for weeks at a time that have problems that are mostly solved by a simple restart. Apple doesn't believe their computers can have problems. They have gutted their "First Aid" utility (thought it is still a good thing to run if you have problems), and removed a physical power button. Though it's still kind of there. I just can't think of a good reason to not shut off your computer every night, and thereby helping it run better. This goes for any OS. Save progress is any software you are using and close that software. If you leave your computer on all the time because it is very slow to start or open programs, then that is a problem with your computer that needs to be fixed. Software can't run well on machines that don't run well. I run MuseScore 3 on a low end, 5 year old laptop and have no playback problems. I try to keep it cleaned out. The only change I have made to it is that I have an SSD in it after a HDD fail. I put it in myself. Pretty simple really. Not rocket science, and not expensive. Not for everyone, I know. Sure, we all just want to turn on our computers and have them work all the time and not have to mess with them. I think that should be a human right. But the fact is that they require maintenance. Just like anything else that is complex. How long will your car last if all you do is put gas in it? Just some thoughts for your consideration.

Reply

• Jul 17, 2019 - 18:48

There are some inaccuracies here (I speak from a lengthy software career including operating-system implementation). Computers should not "fill up with stuff more and more as they keep running as long as the computer is on". People do close documents, web pages, scores, and even applications, and when each such is closed, the resources they consume are released for reuse. Browsers limit how many temporary files, or how much stuff temporary files can consume. I have been using a Mac for 6+ years (infinite years of Windows and earlier systems before that), and it typically runs for weeks, and doesn't "become any slower" as the days wear on. In fact, I keep it on forever (plugged in) and don't have to mess with it. The car model (using it wears it down, like pistons or belts and pulleys) is not applicable. Other than the keyboard (which can wear out), there are no more moving parts.

Reply

• Jul 18, 2019 - 01:29

Actually, I agree. Cars last longer than computers. You know how to use your computer. I know a lot of folks who don't use their's the way you do. They have ten browser tabs and three or four large programs open so they can switch back and forth quickly. I'm not just talking about the ram and storage an application uses. It's also about all the things that go on in the back ground. The housekeeping, record keeping, updating, all of which there is a lot. And it's not just about temp storage. Why do you suppose that Apple still has a utility to repair permissions? Permissions can't be fixed by a restart, but other problems might be. The registry in Windows can be a problem, too. Heat is the worst enemy. What if the fan (moving part) quits in the night, or the SMC system gets corrupted. There must be a reason there is a simple reset procedure. Or the PSU fails (moving part in a desktop). Or the HDD (moving part). Sure, new computers don't have fans, or spinning discs, or even a power button as such. There used to be discussion about not turning off a computer based around heat issues. It has just been my personal experience that turning off a computer does more good than harm. That's all I'm saying.
I'm not sure that leaving it plugged in is the same as leaving it turned on. Plugged in uses less electricity. One computer left on all night may not use much electricity, which is debatable. But millions left on? There is new evidence that our carbon footprint from all our electric gizmos is fast becoming a big problem. My desktop and all it's peripherals are plugged into a power strip that controls what gets power when. The tower has power to it all the time. Turn on the tower and the strip sends power to everything else. turn the computer off, and power is cut to everything but the tower.

Reply

• Jul 18, 2019 - 02:18

I have many large apps open, including three browsers, MuseScore, Libre Office, iTunes, maps, Pixelmator. The Mac knows how to handle virtual memory. It is not clear that turning modern computers on and off is better or worse for them than leaving them on. See web discussions of this. I did have to buy a new Mac after 6 years because of performance problems with MuseScore (solved by new Mac), keyboard problems, and running out of pseudo-"hard disk". And I have never, ever had a problem with permissions. I leave it plugged in to keep the battery charged. The battery can be worn out by enough charge cycles. With MacOS, almost every app saves its state through system shutdown. Today's computers expect, and are prepared for, 24/7 consciousness. That was not the case 25 years ago (although even then I had tower-style servers up 24/7); Things have changed. Re, carbon footprint, the mac sleeps at appropriate times.

Reply

• Jul 18, 2019 - 16:28

Sure, I leave my laptop plugged in 24/7. That's not the same as leaving it on 24/7. I've already referenced discussions about turning computers off. Servers are an entirely different thing. Windows will open programs where you left off after a shutdown, also. I turned that off. It will sleep automatically. I turned that off. Excellent that you've never had a problem with permissions,or SMC.
All I'm saying is that in my experience, so many problems have been fixed, both mac and pc, by a simple restart, that I hedge my bets and just shut the thing down. All personal preference.

Reply

• Jun 20, 2022 - 16:40

Hi, I've read all the comments in this thread. My issues with stutters in Playback began earlier this year in February with two other laptops. My old one and a new one that I returned. Now I am on a 3rd laptop. I have an HP Ryzen 5 AMD using AV Linux with MX21.1 Wildflower and Debian 11 (bullseye). Disk 155 GB Ram 2.13 GB. MS 3.6.2. Surge Protector 1000AVR CyberPower.

The issue began on this laptop on Friday, 3 days ago. While I was listening to a program on YouTube, I opened up Musescore. Perhaps there was an overload of work for my laptop and it confused MS?? Anyway, the problem was immediate. Crackling, crashing sounds, stuttering BOTH ON YouTube, Zoom and when I played my composition in MS.

After that ALL my tests have been using the "untitled new page". If MS worked on that, then I went to my own scores, but, generally nothing was sustaining for longer than a few minutes. I immediately shut down the computer. Here are the steps I've taken to try to resolve this issue:

  1. Unplugged the 2 cameras and aux speakers from the laptop AND from the power surge protector. This corrected the problem previously, as I found that previously my camera actually TOOK over the entire computer and as before, this DID help restore regular sound on YouTube, but not on Musescore.

  2. Reset the I/O numerous times. Sometimes it helps for a moment, then the problem is back.

  3. Since I've had problems with electricity on this side of our house, I bought an extension cord, and plugged it in across to the other side. This didn't correct the MS, but it's probably a good idea. Reset I/O. Didn't help MS.

  4. I read this thread...then I cleaned my Temp files using the Terminal. I was able to go from 28K to 12K in Temp file. That still didn't help the MS. Although I tested... YouTube and Zoom audio through (one at a time) headphones, aux speakers and laptop internal speaker are working fine. Reset I/O. Tried MS through the different audio devises...all still crackling, etc.

  5. I've wanted to use different soundfonts, but haven't really explored that. Presently there are only 2 on my MS, MS General HQ 1.2.0 and MS Drumline 1.3.1

Not sure what to do now? Do I need to remove MS or do a factory reset or download a new program?

I love MS, so I'm hoping to resolve this, thank you. Sora

Reply

• Jun 20, 2022 - 19:59

Hi! I would suggest going to Edit / Preferences / I/O, and whatever setting you see there, try others one, and see if something works better than whatever is selected now.

Failing that, the issue probably has to do with the configuration of the audio on your system. MuseScore uses different facilities than other programs, so the fact that other programs don't have the issue doesn't mean the problem isn't with the system. Unfortunately, I'm not enough of a Linux sysadmin guru to advise further.

Reply

• Jun 20, 2022 - 20:12

Thanks, Marc.

FYI, I just retired this week...so hope to be a bit more engaged with all...

I think I need to learn more about the audio from AV Linux. I'll start looking for someone or more videos...maybe contact Jim Ivy, he helped before with other issues.

And excited for all the great work you and everyone is doing at Mastering Musescore community (want to listen to the harp Cafe :)! and get into some of the lessons...but first to fix my MS!

Reply

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