Why changing MUS/MIDI track causes jerking?

[Caleb13]

Ever since I started using Zdoom and its successors, I noticed that there is jerking when a MIDI/MUS music track changes. How bad it is depends on MIDI synth used, it is slight with Fluidsyth or old FMODex, and very bad with MS GS synth or LibOPN. Probably the worst is LibADL, it causes the game to freeze for half a second on Threadripper 1950X. Conversely, some synths produce no jerking at all, GUS, OPL and TiMidity, for example. I'm curious why this happens, I mean, we're talking about playing prehistoric MUS/MIDI files that have 50 kB at most.

I'm attaching a WAD that showcases this via ACS script. It switches two MUS tracks every 10 tics and with some synths, the game becomes unplayable while the script runs. I also have another WAD that switches MUS, MOD and MP3 tracks every 3 seconds and the jerking occurs only when the MUS track starts. But that one is too big to attach here (what's the current attachment size limit, BTW?).

You don't even need any mod to test this, though. If you run forward in a large map and type the IDMUSxx cheat, you can see the jerking occurs, too.

[Graf Zahl]

While MIDI itself is cheap, the sound fonts are not.Timidity, GUS and WildMidi can cache the sound font between songs so switching is fast, except for the very first song, which is the intro tune in the menu. OPL does not load anything so it's also fast. FluidSynth needs to reload the sound font for each song which can cause a small hiccup. Microsoft GS is outside our control but should be similar to FluidSynth, but due to its age it's not surprising that it is a bit worse.
I have no idea why ADL and OPN are the worst, by all accounts they should be cheap, they do not load much data, in particular no waveform sound font that may cost loading time.

[Wohlstand]

I see, you do a full reload of libADLMIDI and libOPNMIDI when changing the music. Those libraries are doing the initialization of the chip emulator and the bank files. It's not required to reload the entire library if changing songs: you can simply call the `opn2_reset(Renderer)` or `adl_reset(Renderer)` to make the full reset of MIDI state from last given by previous songs. Changing the bank also doesn't require you to reload the whole library: bank change will also don't affect kept MIDI state: there are only all notes will be off, however, all controllers and pitch states will be kept untouched until you'll call `*_reset()`. The only reason to unload and load the library is a switching of the MIDI library. I'll try to make some by myself and I'll send a commit. The library load time depends on a chosen chip emulator. As a temporary workaround, you can choose one of the simple emulators that don't eat power: for libOPNMIDI, there are Neko Project II Kai (suggested), PMDWin (a bit dirty), and GENS (inaccurate envelopes and bad SSG-EG support). For libADLMIDI, the DosBox emulator is the fastest.

[Wohlstand]

I also think, here is some sort of the wave cache resetter that makes a delay for the case of powerful chip emulator being used:
- when MAME or GENS emulator is used, it works fast.
- when Nuked OPN2 emulator is used, ot works VERY slow: this especially one is a very cycle-accurate chip made from original chip's die and it does the same hardware logic with few optimizations. The accuracy does cost of performance: at me, it can work with no lag with 3 chips only. On GZDoom if you'll use this emulator, the pre-start delay will appear (probaby because of automatic latency adds to music stream with the heavy Nuked OPN2 emulator).
Even I had to enforce the re-usage of the same OPNMIDI's instance for the experiment (I saved the instance at the static unique_ptr variable), it still give the song start delay when using powerful emulators.

[Wohlstand]

Okay, even I made the workaround to completely don't touch libOPNMIDI's configure calls, leaving the only initial setup that I call at one load moment, the inter-song lag depends on the power of a chip emulator that was selected for use, and I see it seems that the inter-song delay was caused by the audio cache filling that doing out of my libraries somewhere at ZMusic or lower... If using a fast emulator, you'll see a small lag even with "OPL Synth". With libOPNMIDI, I see that when using MAME, GENS, or NPII, the lag is still being minimal. However, when selecting the Nuked OPN2, you'll meet the strong lag. At least the time of library loading is very small even there is some left to optimize.

the worst is LibADL

Because of the same reason, if you use the Nuked OPL3 emulator, the lag will be. You can choose the DosBox emulator to reduce the lag.