Re: [fluid-dev] Patch for bad MIDI timing (with large buffer sizes)

[David Henningsson]

Pedro Lopez-Cabanillas skrev:
> David Henningsson wrote:
>>> * file output driver (fluid_aufile.c) uses another timer instance. This
>>> should be fixed as well, to solve ticket #15.
>> Agreed.
> Please take into account that the file output can be used also without 
> rendering a MIDI file, when FluidSynth is used as a real time MIDI 
> synthesizer. In this case, the clock timer needs to be preserved, unless you 
> find a better solution.

We also have the case where the user wants to play a MIDI file, play
along himself, and put the result into a file. So we can only enable
fast rendering if we have both -i, and -n, and file output, and the
player does not use system clock timers. Did I forget something?

>> But fluid_player_join becomes somewhat obsolete/deprecated with the new
>> solution, and should be replaced with a fluid_player_get_status function
>> (and possibly some kind of callback when status changes).
> The API backward compatibility must be preserved in trunk. 

Agreed.

>>> * MIDI rendering is delayed by one block, this needs some compensation.
>> Can you elaborate? I think this happens for the first block, but not the
>> other ones, right? (Btw, in the old/current timer solution, I guess the
>> delay is a bit random, which must be even worse?)
> Right, the first block will render always silence, and the second block 
> renders the leading MIDI events. It would be better to start one block 
> earlier. This is not very relevant, though.

Fixed here anyway.

>>> * Ensure that the MIDI rendering ends before the last audio block has
>>> been sent to the output device. It would need even some additional time
>>> if there is some reverb or other effects applied.
>> I assume that should read as "Ensure that the MIDI rendering DOES NOT
>> end...". Anyway, I see this as a separate issue unrelated to my patch. I
>> reinstalled fluidsynth 1.0.8 from the Ubuntu archives and got a working
>> -i switch, and confirmed that the issue is present there as well (the
>> program quits too early, especially with a large audio.period-size).
> Yes, you understood what I mean: when rendering a MIDI piece, be sure that 
> the 
> last note can always be fully heard, and even a little bit beyond it.

This is actually two problems in one (both complex enough to start
separate threads about them...). The first, and I assume harder, problem
is to determine when the sounds actually stop. Here we have to take into
account reverb/release, what to do if the last midi event is a note-on
(for a pad sound that never stops), etc.

The second problem is that we have to wait for all audio buffers to be
played before we quit the application, it's not enough that the player
has finished. When I said that fluidsynth quitted too early, I was
talking about this second problem.

I don't plan to solve either one currently, my current goal is to fix #15.

// David