fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pedro Lopez-Cabanillas
Subject: Re: [fluid-dev] Patch for bad MIDI timing (with large buffer sizes)
Date: Sat, 14 Mar 2009 23:11:23 +0100
User-agent: KMail/1.9.6 (enterprise 20070904.708012)

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.

> > * fluid_player_join() must be fixed.
>
> My alternate implementation of that one should work (does anybody know a
> sleep function for macos 9?). Actually it was the comment that misled me
> into believing that fluid_player_join was only called when playing has
> already stopped (which is wrong).

No idea for Mac OS9. For OSX:
http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man3/sleep.3.html

> 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. There is a branch 
for FluidSynth 2.0 developement where API changes are allowed (after 
persuading Bernat about that).

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

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

Regards,
Pedro




reply via email to

[Prev in Thread] Current Thread [Next in Thread]