Aeolus Organ Synth crashes on pedal entry, locking up MuseScore
1. Load attached score.
2. Press Play
Result: the Aeolus Organ Synth should crash on the second note of the pedal entry, halting playback
This has been reproduced on a Sony Vaio Laptop running XP Pro SP3/R5659 and an Acer Aspire Netbook running XP Home SP3/R5651
The crash completely locked up the Sony Vaio but wasn't as severe on the Acer Netbook - I was able to shutdown MuseScore without powering down the machine. Marked critical due to this crash.
Both machines have a variety of Realtek HD soundcard as is common on most portable comuters these days.
| Attachment | Size |
|---|---|
| bwv565.mscz | 35.35 KB |
Comments
I've done some testing since the last post.
It seems that Division III and Pedal Division of the Aeolus synth are unstable.
I created the attached test piece to try this.
It seems to be the Aelous synth itself that crashes as I have tried it on a variety of soundcards: Realtek HD in 3 flavours, Turtle Beach Santa Cruz, and SBLive WDM (I've finally got my old DAW workstation running again)
In each case the synth is 99.9% certain to crash shortly after the Score output is switched to the Aelous Pedal Division and there is a small chance that it will crash when switched to Aeolus Division III - that has only happened twice in the testing run of about 20 plays on different hardware setups. Occasionally the Pedal will play through fine - if it does then you can play it again and it will not crash.
This suggests that soemthing is awry in the initialisation process of the synth, probably during MuseScore Startup.
The severity of the crash varies from completely locking up the computer with 100% processor activity to the MuseScore synth crashing but being able to shut down the application normally.
I do wonder whether it is advisable to include Aeolus in the 2.0 release. Ir is an awesome pipe organ emulation, but development appears to have ceased, the mailing list is absolutely dead, and all the internet resources are gradually dissolving away - the homepage link on Muse ends up in a domain name park, the wiki has now gone, and there seems to be no way at all to access the documentation required to generate more stops, which will be needed to successfully perform the different schools of organ music.
All tests were done on Windows XP of different flavours, and with a variety of versions of 2.0, the latest being R5663
Here is the current aeolus home page : http://users.skynet.be/solaris/linuxaudio/aeolus.html
The internet archive has a backup of the Wiki
http://web.archive.org/web/20100401152409/http://www.muse-sequencer.org…
I do agree that without a good documentation and someone dedicated to make Aeolus live in MuseScore, it will be hard to deliver a working version.
If you can direct me to the documentation required to generate more stops then I will gladly assist in the generation of more.
Sadly all the resources you have provided in the previous post give no indication of how this is done :(
It would seem that this is fixed.
Aeolus is now working perfectly on my Vaio laptop.
Please revert if necessary
I just tried to play the file of #1 and I obatined a crash. Unfortunately, the bug does not seem to be fixed yet.
Windows 8, MuseScore rev. 48a9d230 (self-build)
It crashed during playback in the second measure of the last line.
Here is the backtrace from gdb:
Program received signal SIGSEGV, Segmentation fault.[Switching to Thread 6440.0x7b4]
0x007b8d43 in Pipewave::play (this=0x18713484) at C:\Git_packages\MuseScore\aeolus\rankwave.cpp:165
165 *q++ += p [0] + y * (p [1] - p [0]);
(gdb) bt
#0 0x007b8d43 in Pipewave::play (this=0x18713484) at C:\Git_packages\MuseScore\aeolus\rankwave.cpp:165
#1 0x007b9d43 in Rankwave::play (this=0x13ca4288, shift=1) at C:\Git_packages\MuseScore\aeolus\rankwave.cpp:437
#2 0x007b2e1a in Division::process (this=0x15d015a0) at C:\Git_packages\MuseScore\aeolus\division.cpp:55
#3 0x007b3a39 in Aeolus::process (this=0x13cac418, nframes=1024, out=0x107121f0)
at C:\Git_packages\MuseScore\aeolus\audio.cpp:176
#4 0x0078dc9e in Ms::MasterSynthesizer::process (this=0x13cb9898, n=1024, p=0x107121f0)
at C:\Git_packages\MuseScore\synthesizer\msynthesizer.cpp:278
#5 0x0049f6f4 in Ms::Seq::process (this=0x14c10020, n=1024, buffer=0x107121f0)
at C:\Git_packages\MuseScore\mscore\seq.cpp:645
#6 0x005bfceb in Ms::paCallback (out=0x107121f0, frames=1024) at C:\Git_packages\MuseScore\mscore\pa.cpp:47
#7 0x65344e3d in NonAdaptingProcess () from C:\Git_packages\MuseScore\win32install\bin\portaudio.dll
#8 0x6534602f in PaUtil_EndBufferProcessing () from C:\Git_packages\MuseScore\win32install\bin\portaudio.dll
#9 0x653520c3 in ProcessingThreadProc@4 () from C:\Git_packages\MuseScore\win32install\bin\portaudio.dll
#10 0x75558543 in UnregisterBadMemoryNotification () from C:\windows\SysWOW64\kernel32.dll
#11 0x1070b0e8 in ?? ()
#12 0x77adbf39 in ?? ()
#13 0x77adbf0c in ?? ()
#14 0x00000000 in ?? ()
(gdb) info locals
d = 0
k1 = 0
g = 1.7376101e-043
t = 0.999999583
q = 0x15d1f004
p = 0x18821184
k2 = -30062
r = 0x0
i = 0
dg = 4.48415509e-044
y = 1.00358295
dy = 8.71124826e-008
(gdb) print q
$1 = (float *) 0x15d1f004
(gdb) print *q
Cannot access memory at address 0x15d1f004
(gdb) print p
$3 = (float *) 0x18821184
(gdb) print *p
$2 = 0.0463935696
(gdb) print p[0]
$4 = 0.0463935696
(gdb) print p[1]
$5 = 0.0443404056
Hmm - I just tried that file too and my computer sound system crashed resulting in pink noise.
One caveat here is that file was produced on a very early version of the MuseScore trunk, and thus may contain data incompatible with the current versions of the nightlies.
I will upload the latest version of that demo. - it could be the file that is the problem.
Here it is.
This version plays through fine on my Windows 8 machine using MuseScore2 commit e00c711
Please will other people test this so can we ascertain whether it is the file that is the problem at #1 and not the synth, as I really want to close this if possible.
I think it is a problem of numerical rounding, which at some point in the processing algorithm makes k2 (or k1 and then k2 in the instruction k2=k1) a negative integer. From this point, then, the while-loop
while (k2--)becomes an infinite loop which (in principle) infinitely fills memory pointed by pointerq.It happens randomly. Try with the attached file, created from scratch with a personal build of 1d3dcf3bd .
If you play it (with repeats enabled: I set 10 repeats), maybe a few times consecutively, at some point it crashes.
I think the fix could be to prevent k1 and k2 from becoming negative (i.e. forcing them to be 0 if they are <0), but I should study in more detail the algorithm to see if this could cut some harmonics (k1, for what I understood, is the number of the harmonic).
I have been doing some testing of my own, and it the crash seems to be connected to the use of reed stops, particularly in the pedal. These particular sounds have rich harmonic structures, which may be why they are more prone to crash the synth.
So far it has always manifested itself as pink noise in the sound system rather than a complete crash. MuseScore itself doesn't crash on my system..
I'm currently preparing a set of test files designed to give the Aeolus synth a good work out - will post them here when I've done.
I tried ABL's file and played it a few times without a crash.
I then set the repeat iterations to 100 and set the file going again - no crash.
Windows 8
MuseScore2 commit e00c711
In the absence of anyone else being able to reproduce ABL's crash....
I am marking this as fixed
Ok.
I found that the crash happens only if MuseScore is compiled in DEBUG mode. In RELEASE mode [which is the one used for the Nightly builds and, of course, the release :-) ] MuseScore does not crash.
I still can't understand why the two builds behave differently in this case.
I tried to post a pull request ( https://github.com/musescore/MuseScore/pull/416 ) with a "brute force" solution to avoid the crash. In principle, it shouldn't introduce any difference in RELEASE build (where there is no crash), but would help with the DEBUG build.
@ChurchOrganist: Do you still obtain the "pink noise" you were mentioning in previous comments with recent Nightly builds?
(In particular a rather serious memory leak during playback has been fixed in the meantime, and this could help a lot the playback of long pieces)
I haven't noticed it lately.
Automatically closed -- issue fixed for 2 weeks with no activity.