Bug report: Windows 7 crippled by blank MIDIs

Windows 7 causes ports playing MIDI to pause every time the MIDI loops, so the tiny short blank MIDI that is being used as a placeholder renders ports such as Eternity completely unplayable, as they start to be interrupted constantly.

AFAIK there is no port-side fix to this other than to disable music entirely. I think it would be better if the place holder MIDI was not actually blank but was silence of a given reasonable length, say 3 minutes.

Is this change possible to make, or do I need to hack Eternity to disable music automatically in FreeDoom until suitable music has been written for all the songs?

http://free.doomers.org/

Fixed awhile ago, i think. Replaced all blank midis with whatever was in repo. Most of the Dave3d music was added and there still room for more!

The blank midi problem crashed boom202. 0.6.4 release was specifically to replace the copyrighted music that got in so blanks were added.

http://git.savannah.gnu.org/cgit/freedoom.git/tree/status/musics_list
http://git.savannah.gnu.org/cgit/freedoom.git/tree/status/doom1musics_list

Anyway, if you guys ever do want to use a blank midi again use this one instead. There's actually a note being played for 30 minutes but the volume is set to 0.

Here it is: http://ralphis.unidoom.org/stuff/blank.mid

Sounds to me like SDL_mixer needs a new Windows native MIDI backend.

fraggle said:

Sounds to me like SDL_mixer needs a new Windows native MIDI backend.

I wish I could find out what the root cause of it is, but it's almost certainly something to do with the lack of the high-precision timer API that was originally used by MCI under XP and prior, but was removed in Vista.

Whatever it's doing in lieu of that causes the entire program to be preempted when the song loops. Input stops, digital sound starts to skip, video cannot be drawn. The process is locked, effectively. It is for a very brief period of time, but it is still annoying.

Quasar said:

I wish I could find out what the root cause of it is, but it's almost certainly something to do with the lack of the high-precision timer API that was originally used by MCI under XP and prior, but was removed in Vista.

Whatever it's doing in lieu of that causes the entire program to be preempted when the song loops. Input stops, digital sound starts to skip, video cannot be drawn. The process is locked, effectively. It is for a very brief period of time, but it is still annoying.

You could always push notes to be played like I do for ReMooD, all low level. You'd have to handle timing yourself however and load all the data yourself also.

GhostlyDeath said:

You could always push notes to be played like I do for ReMooD, all low level. You'd have to handle timing yourself however and load all the data yourself also.

Yeah this is what EDGE does, however it uses an old WIN32 timer callback system, timeSetEvent(), which is not good nowadays (it may even be deprecated now). Ideally the code would be using threads.

This is the code:
http://edge.svn.sourceforge.net/viewvc/edge/trunk/edge/src/w32_mus.cc

andrewj said:

Yeah this is what EDGE does, however it uses an old WIN32 timer callback system, timeSetEvent(), which is not good nowadays (it may even be deprecated now). Ideally the code would be using threads.

This is the code:
http://edge.svn.sourceforge.net/viewvc/edge/trunk/edge/src/w32_mus.cc

http://remood.svn.sourceforge.net/viewvc/remood/trunk/src/sdl/i_music.c?view=markup

Respectively. Uses threads (if enabled).

AFAIK SDL_mixer's MCI callback is dispatched asynchronously from a winmm thread being run directly by kernel32.dll, because this is where the stack dump comes from when SDL crashes due to its multicore bug.

Of course the fact the multicore bug exists in the first place means there must be some serious problems in the implementation of this stuff.

Quasar said:

AFAIK SDL_mixer's MCI callback is dispatched asynchronously from a winmm thread being run directly by kernel32.dll, because this is where the stack dump comes from when SDL crashes due to its multicore bug.

Of course the fact the multicore bug exists in the first place means there must be some serious problems in the implementation of this stuff.

Do they use mutexes or whatnot at all?

GhostlyDeath said:

Do they use mutexes or whatnot at all?

I don't see any attempt at guarding the data that the callback accesses, and I already earlier identified at least one possible race condition that can occur when stopping a song. I reported it to SDL and they declined to fix it.

Sice the latter half of the Vista age, hardly anything related to using doom on a more chocolatey source port won't work (very well).

Windows 7 (ie, slightly upgraded Vista) suxs with midi in general -- a lot of professional music software won't even run Vista or Windows 7.

I do not program Windows anymore, and I do not know if this even works in Linux, but a thought is to fork a separate process just to play the midi, and let Windows pause that one. Then you can do a proper communication with the new process to tell it which MIDI to play.
I know that Legacy runs three processes to play a game, and one is doing the music.

Of course, you may already be using a separate music process,
or Windows could be stopping all I/O to do some MIDI thing, or
Windows could be running a high-priority task (that is in a wait loop)
to get the MIDI started (because some media player needed it that way) and I wouldn't be surprised if it is the third one.

You could check the MIDI file/lump length and ignore any that are under 100 bytes long.

If more desperate, you could tweak the QUS midi converter to estimate
play time, and if too short, then duplicate multiple copies into the output buffer until some minimum play time criteria is met. That way the system does not get a short midi.

Could put a short engine generated midi (5 or 10 seconds of silence) appended onto short midi lumps, to extend them.