High density of MIDI events slows down playback tempo

[mrbumpy409]

Where there are a lot of MIDI events (for example, rapid MIDI CC modulation), dmidiplayer slows the tempo down, sometimes considerably so. This happens regardless if sending MIDI to an external player or using the internal FluidSynth. When this happens, the player's CPU usage remains quite low, so it doesn't seem to be a CPU limitation.

I have attached dmidiplayer event density test.zip for reproducing the issue. It contains the following files:

• dmidiplayer event density test.mid – This MIDI file should play at 138 BPM, but it plays significantly slower than that. The metronome lights in dmidiplayer, however, still tick at 138 BPM. The culprit is the fast CC7 modulation on channels 1 and 2. If you remove these events, dmidiplayer will play correctly at 138 BPM.
• midi event density test-FluidSynth.ogg – This is the density test MIDI played using the FluidSynth command-line sequencer. The tempo is correct.
• midi event density test-dmidiplayer.ogg – This is the density test MIDI played using dmidiplayer routed to Qsynth. The tempo is too slow.

The SoundFont used in the recordings is the release candidate for GeneralUser GS v2.0.0, but any GM/GS SoundFont should suffice for testing this bug. Also, this bug happens in both Linux and Windows on my system, which is detailed below.

My System

• dmidiplayer: 1.7.3
• OS No.1: KDE Neon 6.0 User Edition (Plasma Desktop 6.1.2, KDE Frameworks 6.3.0, Qt 6.7.0)
• OS No.2: Windows 10 Home Edition
• OS No.3: Windows 10 Professional running in Virtualbox under KDE Neon
• CPU: Intel Core i7-990x Gulftown (3.46 GHz hexa-core, Socket 1366) @ 4.15 GHz

[pedrolcl]

Hi Christian! Thanks for the report and the sample song. I can confirm the bug of tempo slowed down, and that it does not depend on the CPU. It seems some miscalculation. But I think that the rhythm lights are also affected. To me, the "leds" tick well synchronized with the music: from bar 10 the snare drum sounds exactly on the second and fourth beats synced to the corresponding "leds".

[mrbumpy409]

To me, the "leds" tick well synchronized with the music: from bar 10 the snare drum sounds exactly on the second and fourth beats synced to the corresponding "leds".

Interesting. I'm seeing it completely desynchronized here using the Flatpak version in Linux. Either way, I'm glad you were able to repro the issue. dmidiplayer is everything I want in a simple MIDI player, so thank you for creating it!

[pedrolcl]

Sorry for not updating the ticket in a long time, but my available time was scarce, and also this issue was difficult to diagnose. Here is a little report just to inform you about my findings and tentative solution.

Your MIDI file has a fixed tempo of 138 BPM and a length of 19 bars which allows to easily calculate a theoretical duration of 31.3 seconds. Your OGG rendering using dmidiplayer is 33 seconds. In my tests with v1.7.3 rendering your clean MIDI file (removing CC7 events), the length is 31.5 seconds, but the full one is 34.8 seconds, which is noticeably slow.

The problem is an accumulation of inaccuracies in time calculations, which were made in milliseconds (1 ms = 10^-3 seconds).

If you open the MIDI file with kmidimon, you may notice that the tempo event (located in the first track) says that the tempo is 434783 microseconds per beat, which is how the standard defines 138 BPM. One microsecond is a millionth of a second (10^-6 seconds). The fix, applied to the 'devel' branch, calculates times in microseconds. With this precision the inaccuracies are now much smaller, and the renderings of your MIDI file are: clean=31.4 seconds, full=31.9 seconds.

There are still some pending optimizations that may improve the results in the next release, along with several other fixes and improvements. Thanks for your patience!

[mrbumpy409]

I am so glad you were able to find the cause! I look forward to testing the new build. :smile:

[pedrolcl]

I am so glad you were able to find the cause! I look forward to testing the new build. 😄

Here is a pre-release: (removed)

[mrbumpy409]

I've only tested one MIDI file so far and found that new build is playing way too slowly with lots of tempo fluctuations. Here is a zip file containing the following:

• dmidiplayer_j-cycle.mkv – video showing the first part of J-cycle.mid playing in dmidiplayer.
• dmidiplayer_registry_settings.reg – the player settings I am using (registry).
• FluidSynth_J-cycle.ogg – J-cycle.mid played using the FluidSynth command-line application.
• J-cycle.mid – the MIDI file that triggers the slowdown

You can hear the correct tempo in FluidSynth_J-cycle.ogg vs. how much slower dmidiplayer is playing it.

[pedrolcl]

I've only tested one MIDI file so far and found that new build is playing way too slowly with lots of tempo fluctuations.

J-cycle.mid has only three tempo changes. It has several time signature changes, though, but they do not influence the playback, because it is only a notation meta-event:

The OGG rendering is has a duration of 1m 40 seconds, which is the same as this one. I've just rendered it with dmidiplayer on Linux, without issues. Here is the movie:

jcycle-2024-08-29_10.39.00.zip

[pedrolcl]

Testing the same MIDI file in Windows, the timing is awful. I've increased the player thread priority (which only affects Windows) in commit 1289d6b. Tell me if it improves something:

Windows: dmidiplayer-1.7.4pre3-win-x64-setup.exe Linux: dmidiplayer-1.7.4pre-x86_64.AppImage

This pre-release builds include drumstick-2.9.1 released yesterday.

[mrbumpy409]

Both of those application links give me an error from SourceForge, such as: The "/v1.7.4/dmidiplayer-..e2-win-x64-setup.exe" file could not be found or is not available. Please select another file.

[pedrolcl]

Both of those application links give me an error from SourceForge, such as: The "/v1.7.4/dmidiplayer-..e2-win-x64-setup.exe" file could not be found or is not available. Please select another file.

Sourceforge offers a link "Problems downloading?" so you can choose a different mirror. The files take some time to propagate to all mirrors.

[mrbumpy409]

Alright, I tested the latest preview builds. The Windows build still plays back with a slow and fluctuating tempo, but the Linux build seems to play perfectly in time. How odd. :thinking:

[pedrolcl]

Alright, I tested the latest preview builds. The Windows build still plays back with a slow and fluctuating tempo, but the Linux build seems to play perfectly in time. How odd. 🤔

What we need here is many tests, to discover if some other songs are affected by the same symptom. I can't exclude some other calculation mistake, but in that case: why the results are different in Windows and Linux? Other sample MIDI files have multiple tempo changes, like Schubert_Standchen.mid that render exactly the same on Linux and Windows.

[mrbumpy409]

I'll see if I can make some useful test files over the next few days. Thank you for all the work you have been putting into this player! Hopefully I can be more of a help than a nuisance. :stuck_out_tongue:

[pedrolcl]

What happens if you replace the DLLs in this ZIP file into C:\Program Files\dmidiplayer\ ? cxxruntime.zip (spoiler: it fixes the timing problems for me)

[pedrolcl]

New Windows package: dmidiplayer-1.7.4pre3-win-x64-setup.exe

[mrbumpy409]

I tested a bunch of MIDI files with the latest Windows build, and the tempo stability seems pretty solid to me. I would say the issue indeed appears to be solved! Also, everything is sounding fantastic with the new reverb & chorus settings. :smile: