Problems with short duration note events

[jgreen]

This issue was originally brought up by Antoine Schmitt on the fluid-dev mailing list. Antoine found that short note durations (around 7ms duration percussion events in his tests) were being lost and would not sound at all. This appears to be a problem with the way in which FluidSynth processes events. Although the internal FluidSynth audio buffer is usually 64 samples, audio drivers typically process segments of audio in much larger chunks, which leads to note on/off events of short notes occuring within the same audio block. A re-design of the event system is likely in order. Link to start of original thread: http://lists.gnu.org/archive/html/fluid-dev/2007-05/msg00000.html

[diwic]

With the new sample timers, I expect the problem to persist but only for notes shorter than 64 samples.

[diwic]

Ok, so this obviously needs to fixed. I haven't looked closely into the source yet, but I suspect that the problem is that FluidSynth seems to be doing the right thing according the soundfont specs, quoting: "Whenever a key-off occurs, the envelope immediately enters a release phase during which the value linearly ramps from the current value to zero." Now even how fast attack we have, if the note-off comes immediately after, the attack has not yet begun and we ramp from zero to zero - and no sound is heard. As drum pad and drum tracks often to just that (a note-off just after the note-on), this is bad.

So my suggestion is that we set a fixed minimum delay between note-on and note-off, so that the note-off is delayed if it comes too early. Drums often have a very fast attack so that would probably solve the problem without disturbing other things. I guess a good value could be between 1 and 20 ms, and we could either hard-code the value (without anyone ever noticing, probably), or make it a setting.

Comments?

[KrzysiekK]

I actually wrote a temporary workaround for the problem few months ago, according to debug observation of events flow, and so far it's been working fine. It is delaying noteoff to allow at least one voice block for processing; then the event is artificially released by checking buffer memory. I can provide code to anyone interested (haven't done it yet officially as the code isn't optimized and may possibly introduce some performance loss).

[jgreen]

Support for this was just recently added into subversion trunk and will be available in 1.1.0. There is a setting synth.min-note-length which sets the minimum note duration in milliseconds and defaults to 10ms. Thanks for your interest in fixing this long outstanding bug! I think we can call it closed.