Timing inconsistencies in MIDI File Player in Windows?

[jimhen3ry]

We use callbacks from the MIDI file player in our Windows app. It seems like there is a rather large amount of inconsistency in the timing of received events. Based on the tests run so far, the length of a nominal 236 mSec. note (on to off) appears to be 218 to 243 mSec. Are there any known issues we should be aware of before we dig deeper?

[derselbst]

Why does it matter that the timing of the received events matches the length of the note? Depending on how many events there must be dispatched you may receive the callback of a particular event sooner or later. What matters is the there are no inconsistencies in the generated audio.

[jimhen3ry]

I guess I wasn't clear about the issue that we think we are seeing.

The length of the audio generated for a note depends on the timing of when you issue a Note On and when you issue a Note Off. MIDI does not directly encode the length of the note. If there is jitter in the timing of MIDI events and the Note On is delivered late relative to the Note Off, the generated audio for the note will be too short. Conversely, if the Note Off is delivered late relative to the Note On, the generated audio will be too long.

We are hearing jitter issues, inconsistencies in the generated audio, in the Miditzer and we are trying to track them down. We are using MIDI files of arpeggios to generate regular events and trying to pinpoint the source of the jitter, without much success so far. In the last tests it seemed possible that the FluidSynth MIDI file player was not delivering the MIDI events with a consistent relative timing.

Extrapolating from your response, I will assume that there are no known jitter issues with the FluidSynth MIDI file player on Windows, a notoriously bad operating system for real-time programming. We will continue our testing accordingly.

[derselbst]

If there is jitter in the timing of MIDI events and the Note On is delivered late relative to the Note Off, the generated audio for the note will be too short.

If you're using the system timer as timing source for the MIDI player, then delivery of the events depends on when the OS allows fluidsynth to execute and only then it affects the generated audio. However, the default is using the sample timer, in which case the amount of rendered audio is used as timing source. Delivery of the events doesn't matter in this case.

Extrapolating from your response, I will assume that there are no known jitter issues with the FluidSynth MIDI file player on Windows, a notoriously bad operating system for real-time programming

Well, you should be using fluidsynth 2.2.7, cf. the changelog. And you should set all your processes to real-time priority if you care so much about correct timing. That's the only advice I can give for the moment.

[jimhen3ry]

Can you explain using the sample timer as the timing source for the MIDI player a bit more?

The Miditzer significantly translates the MIDI In received from the MIDI player before using the MIDI channel messages to have the synthesizer generate audio. Would the lack of a 1:1 correspondence between MIDI In from the player and MIDI Out to the synthesizer create timing issues when using the sample timer?

Not an issue for the testing we are doing now but it is possible to have real-time input combined with the MIDI player input leading to MIDI output that isn't present in the MIDI player input. Would this create timing issues when using the sample timer?

I did discover that the test version is finding an old FluidSynth version even though we try to stay current on the releases. I need to track that down. Thanks for pointing that out.

[derselbst]

Can you explain using the sample timer as the timing source for the MIDI player a bit more?

" 'sample' uses the sample clock (how much audio has been output) to sequence events, in which case audio is synchronized with MIDI events." - So the one who calls any of fluidsynth rendering functions is implicitly responsible for timing. In other words, the elapsed time is derived from the amount of rendered audio, rather than the systemtimer.

Would the lack of a 1:1 correspondence between MIDI In from the player and MIDI Out to the synthesizer create timing issues when using the sample timer?

If all those translations are performed in the synth context, it would not cause timing issues when using the sample timer.

it is possible to have real-time input combined with the MIDI player input leading to MIDI output that isn't present in the MIDI player input.

I would guess this is possible.

Would this create timing issues when using the sample timer?

I have no clue.