Menu

#2000 Occasional Midi crash when looping on Windows using music_sdl backend

OHRRPGCE
open
nobody
None
backend:music_sdl
Windows (please specify version)
Bug Report
20130410 Beelzebufo
2020-03-15
2014-05-13
No

Sometimes when a midi file loops, it causes the program to crash. This bug is most noticeable on very short midi files that loop rapidly. This only happens when using the music_sdl backend.

See also old archived bug reports:
http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=797
http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=976

Discussion

  • TeeEmCee

    TeeEmCee - 2017-02-19

    This can also be triggered easily if running under wine.

    ticktock in audiotest.rpg is an example of a file that causes the crash.

     
  • TeeEmCee

    TeeEmCee - 2019-08-08

    Lately (last couple of years), I haven't managed to gt that Tick Tock MIDI or any other MIDI to crash and actually I think it was never reliable: I think it only happened if the window was minimised/restored at the moment that the song looped, or something like that.
    But now thanks to KxMP I've found there are two BAM songs in Timestream Saga that cause the engine to immediately freeze 100% of the time. I've uploaded one as testfiles/GURGU.mid

    I can confirm this affects both music_sdl and music_sdl2. But it didn't crash under wine, despite what I said in 2017.

    Also, we have quite a few crashreports for this bug, the stacktrace looks like:

    ----- Stacktrace -----
    @ modUnprepare + 0x6 
    @ modMessage + 0x8 
    @ midiStreamMessage + 0x11 
    @ midiOutPrepareHeader + 0x14 
    @ [SDL_mixer.dll + 0x151cf]
    @ CSynth::PlayBuffer + 0x26 
    @ CSynth::PlayBuffer + 0x1c 
    @ DriverCallback + 0xd
    

    or one-line summary: modUnprepare <- modMessage <- midiStreamMessage
    The dlls are midimap.dll, winmm.dll, SDL_mixer.dll, wdmaud.drv.

    Now, this stacktrace is interesting, because these function names are googlable. There are implementations of midimap.dll, winmm.dll in wine and ReactOS.
    And I found that code for CSynth::PlayBuffer() (real dll: wdmaud.drv) is included as part of a DirectMusic sample software synthesizer implementation in the Windows DDK:
    http://joyasystems.com/sample-code/Windows%20Driver%20Samples%2FDirectMusic%20Software%20Synthesizer%20Sample%2FC%2B%2B%2Fcsynth.cpp
    Now this isn't the actual source code for any of those dlls, and I don't know how similar it is to the real thing, but it can give insight to what these functions are doing.

     

    Last edit: TeeEmCee 2020-02-05
  • TeeEmCee

    TeeEmCee - 2019-08-08

    Also worth mentioning music_native and music_native2. These carry copyright notices saying they're derived from code from SDL_mixer which Mike ported to FB, but comparing the code it's hard to see how they're related, they don't even use the same winapi functions! Mike did some crazy stuff there, it's a pity it wasn't stable enough.

    Anyway, both music_native and music_native2 behave the same: they play that one note while looping the midi after a split second, so it sounds like PTPTPTPTPTPTPTPT. music_sdl makes the same sound, but I thought that was just because it was crashed. They eat 100% CPU while doing so, an every ~5 seconds the program freezes for ~5 seconds, then continues as normal, and repeats.

    I played GURGU.bam with PLAYBAM.EXE under dosbox and to my surprise it's a perfectly normal song. So bam2midi is broken.

     
  • TeeEmCee

    TeeEmCee - 2019-08-08

    Oh yeah, and timidity plays GURGU.mid while looping only after a few seconds, so which is playing the midi correctly?

     
  • TeeEmCee

    TeeEmCee - 2020-03-15

    This bug has been migrated to our new issue tracker on Github: https://github.com/ohrrpgce/ohrrpgce/issues/1060

     

Log in to post a comment.