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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev