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

[Pedro Lopez-Cabanillas]

David Henningsson wrote:
> 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?

There is also the MIDI sequencer case (fluid_seq.c) where you can find another 
timer instance. This would be used by an application scheduling (queueing) 
timestamped MIDI events, for instance a drum machine, or a MIDI arpeggiator, 
or something like that.

The last timer that I could find in the sources is used when unloading sound 
fonts. This is a one shot timer, and should be always a master timer.

Let's call the instance created by new_fluid_timer() a master timer, and the 
one created by your new_fluid_synth_timer() a slave timer. Whenever there is 
a process requesting synthesizer buffers at any rate, like the drivers for 
output audio devices, then you can use the slave timer for MIDI file 
rendering or other usage. The rate of the slave timer would be the same of 
the audio process: if it is faster than real time it would be inappropriate 
for real time usages. If the output is set to an audio device, the slave 
timer is also real time (with the accuracy provided by the audio driver and 
hardware).

An easy solution for the CLI client would be a new option (-O 
filename, --output=filename) processing the faster-than-realtime rendering by  
using your slave timer, setting -i and -n automatically. It would require of 
course an input MIDI file and a sound font in the command line as well.

For the library usage, an option (synth.slave.timer=yes/no) would be enough, 
enabling your timer for MIDI rendering according to the setting.

> >>> * 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

OK. I would open a new ticket for this bug, if you don't open it yourself.

Regards,
Pedro