playback duration of certain MIDI files is different between operating systems

[mrbumpy409]

While testing the recent dmidiplayer 1.7.4 release in macOS, I noticed the tempo of some MIDI files seemed slower than what I remembered. So, I ran a few tests using J-cycle.mid and discovered that the playback tempo is notably slower on macOS compared to Linux or Windows. Note that this phenomenon doesn't affect all MIDI files—a MIDI file I recently made for testing MIDI event jitter plays at exactly the same tempo on all three operating systems. So, to keep things simple, this initial report will focus only on "J-cycle.mid".

I have attached a .zip file containing J-cycle.mid and recordings of that file being played through various players, operating systems, and driver configurations. All audio files have their starting notes aligned for easy comparison in an audio editor. Where dmidiplayer's FluidSynth driver was used, the following parameters were set:

• Period Size: 64 (attempting to avoid this issue)
• No. of Periods: varies for each OS/driver combination—recorded in the filename as <periodSize>x<numPeriods>, e.g., 64x32.
• Sample Rate: 48000
• Reverb & Chorus: all default settings
• Gain: 0.5
• Polyphony: 512
• Sound Font: GeneralUser GS v2.0.0.sf2 (private build, soon to be released, but let me know if you would like a copy for testing)

Here is the list of included recordings, with duration listed prior to the filename (measured from start of first audible MIDI event through the start of the final note/chord):

• 1:38.830 fluidsynth.ogg – played in FluidSynth command line on my desktop KDE neon install (direct to wav file)
• 1:38.831 sfmidiplayer-bassmidi.ogg – played in Falcosoft SoundFont MIDI Player on my desktop Windows 10 install (using the BASSMIDI engine)

The recordings made with the FluidSynth command line (fluidsynth.ogg) and Soundfont Midi Player (sfmidiplayer-bassmidi.ogg) both match tempo perfectly, so I believe these recordings likely represent the correct tempo. I will refer to these as the "reference" recordings.

• 1:42.500 dmidiplayer-coreaudio-64x32 (macOS-HW).ogg – played in dmidiplayer FluidSynth on 2013 Macbook Pro (macOS Big Sur)
• 1:42.652 dmidiplayer-coreaudio-64x32 (macOS-VBox).ogg – played in dmidiplayer FluidSynth in a VirtualBox macOS install (macOS Monterey)

Both of the macOS (coreaudio) recordings drag noticeably compared to the reference, taking almost four seconds longer to complete. The VirtualBox recording is slightly slower of the two.

• 1:36.821 dmidiplayer-dsound-64x32 (Win10-HW).ogg – played in dmidiplayer FluidSynth on my desktop Windows 10 install
• 1:36.950 dmidiplayer-dsound-64x64 (Win10-VBox).ogg – played in dmidiplayer FluidSynth on my VirtualBox Windows 10 install

The Windows (dsound) recordings, on the other hand, are too fast by two seconds duration. Once again, the VirtualBox recording is slightly slower of the two.

• 1:39.273 dmidiplayer-jack-64x4.ogg – played in dmidiplayer FluidSynth on my desktop KDE neon install (using jack driver)
• 1:39.247 dmidiplayer-pulseaudio-64x10.ogg – played in dmidiplayer FluidSynth on my desktop KDE neon install (using pulseaudio driver)

On Linux, the tempo is much closer to the reference recordings, being only very slightly longer.

• 1:37.545 dmidiplayer-audigy2.ogg – played in dmidiplayer to external hardware Audigy 2 MIDI device on my desktop Windows 10 install

Now, here is where the puzzle only increases: when setting the Windows dmidiplayer to output to an external MIDI device (in this case, the Audigy 2 hardware SoundFont synthesizer), the tempo ends up slower than when using the built-in FluidSynth engine, though still almost a second too short of the reference.

Hopefully this report will help shed some light on whatever is causing the tempo variations. Please let me know if you need me to do any more testing.

[pedrolcl]

what is causing the tempo variations

This is expected. A single source code is used on all platforms. The C++ code is using standard features only, which makes it very portable, but also very susceptible to bugs and diverse implementations of the standard runtime libraries. We have seen that some versions of the MinGW runtime for Windows totally ruined the performance of the program, which was solved with only replacing the runtime.

Now, about MacOS: we all know about Apple slowing down the iPhones with each operating system update, just to encourage the customers to buy new hardware. Side note: Apple had to pay $90 to each customer that filed a complaint. Very cheap settlement, I would say. I have a Mac Pro that experienced also slowdown issues until they decided that v10.15 (Catalina) was the last operating system version that could be installed. I guess I am not alone in suffering this abuse and fraudulent practices from Apple. The result is that I will never again purchase an Apple product. I've installed Linux in my Mac Pro, and when it should suffer a serious or unrecoverable hardware failure, I will cease to provide more binary packages, and support for macs.