Zerebus crashing
Ubuntu 14.04.02
KXStudios audio software (via their ppa)
MuseScore 2.0.2 (from KXStudios)
MuseScore I/O = jack
When I try to load the Salamdander Grand Piano .sfz soundfont in the Zerebus tab of the Synthesizer,
it loads to between 17% and 56% (taking up to three minutes or more), then crashes my whole system, requiring a hard reboot.
Comments
The first thing that pops into my head is how huge the Salamander Grand Piano .sfz is. How much total ram is on your machine, how much is free before you boot mscore, and what are your cpu specs? I notice if I boot mscore with only the default soundfont, the memory usuage is about 128 MB. If I then load one Salamander SFZ, then memory jumps way up to 1.4 GB. Then if I load another one, the memory jumps up to 2.6 GB. If your system is memory starved, then that would explain the hang and crash.
Can you open up a system resource manager (usually accessible via ctl->alt->delete), open up a terminal, and boot musescore from a terminal, and report back any messages outputted to the terminal and what happens to your memory usage bar when loading the .sfz?
In reply to The first thing that pops by ericfontainejazz
CPU specs:
Memory before firing up mscore (in Mb):
total used free shared buffers cached Mem: 1874 1016 858 125 11 360 Swap: 1916 0 1916Memory after firing up mscore:
total used free shared buffers cached Mem: 1874 1203 671 130 13 447 Swap: 1916 0 1916Memory after loading Salamander .sfz:
'mscore' isn't spitting anything to stderr or stdout when invoked from the command line.
Observing what's happening with memory while the font is loading, I see that it starts to hang at the moment swapping begins, so yes, it appears to be a memory problem.
FWIW, no other programs I run regularly exhibit this behaviour when there's heavy swapping. On an average day, I can be running a full compositing KDE desktop with all the bells and whistles, the memory hog called Firefox, a file manager, a pdf viewer, a terminal window and a media player and still load something huge like the GIMP—with much swapping— in about 10 seconds. Of course, all this stuff is shut down when I'm working on a MuseScore project.
I normally use linuxsampler (with the full Java interface) to load Salamander, which I do after firing up mscore. The font's a little slow to load compared to others, but the lag is minimal, just a couple of seconds.
In reply to CPU specs: Architecture: by Peter Schaffter
That explains it. Memory is thrashing.
>> On an average day, I can be running a full compositing KDE desktop with all the bells and whistles ...
Usually those programs aren't doing a full pass through their entire memory. i.e. they are loaded, their memory pretty much just sits, and only accessed by cpu when needed. But I think with this .sfz loading, musescore is making a full pass through the entire memory, which would be causing a continuous stream of back-to-back page swaps.
Maybe some of the core devs who have implemented this could comment. My recommendation is that there be some "Cancel" button that user could press if they realize the loading might be causing a hang.
In reply to That explains it. Memory is by ericfontainejazz
Yes, a Cancel button would be a good idea until Zerebus can be implemented more efficiently. Meanwhile, trusty ole linuxsampler handles .sfz fine, so no one need find themselves up the creek without a paddle.
In reply to Yes, a Cancel button would be by Peter Schaffter
I'll see if my feature request gets approved and I'll try to implement: #71441: Add a "Cancel" button for Zerebus soundfont loading & audio export