On 07/31/2013 12:44 AM, ChordWizard Software wrote: > Hi all, > > Greetings from a new user of FluidSynth and thanks for the work that has made > this great library available to all. > > I am using it as a DLL to add soundfont support to the sound engine of my > music application, Songtrix. The sound engine handles the audio stream > directly. > > Typical use pattern on each audio callback (of typically 1024 frames) is: > > 1. Output pending midi events (for time interval) to fluid > 2. Render frames using fluid_synth_write_float > > Both steps are conducted serially via the same thread and this works fine. > > One thing I have noticed is that unlike other softsynths that I am supporting > (such as VST and the DirectMusic synth) the fluid library has no concept of > event timing for placing the pending events exactly into the forthcoming > audio buffer. Is there a specific reason for this? > > I am aiming at sample accuracy of rendering, particularly for offline > mixdown, the absence of timing information implies that all events are being > rendered in the output buffer at the start of each rendered block. For > 1024-sized buffers @ 44100, this is a limit of resolution of 25ms, not so > good. > > One strategy I have tried to achieve sample accurary with fluid, is to > interlace the event triggering and output rendering, in other words: > > 1. Output single pending event (or multiple if all at same time instant) > 2. Render frames up to next event's time instant (or to the end of block if > no more) > > Trouble is, I get significant glitching with this approach and I can't > understand why. It happens with offline processing also, so it is not a > processor capacity issue. > > It seems there is something happening in fluid that works well with large > buffers being rendered, but struggles when many smaller inter-event periods > are rendered as described above. > > Can anyone suggest what may be happening here, and what approach I should try > to find a remedy? I can send demo files if that is helpful.
Hi Stephen, Your approach to output a single pending event and then render frames up to the next event's time instant should work. If this causes glitches, you're either doing something wrong or hitting a bug in FluidSynth. If it is the latter, could you help us track it down and fix it? I'm assuming you use the latest FluidSynth version. As a first step, FluidSynth usually processes data in multiples of 64 samples. If you stick to this rule and always ask for a multiple of 64 samples, does this make the glitching go away? As for the event timing, you can also try using the sequencer object. In the call to new_fluid_sequencer2(use_system_timer), use_system_timer should be false for sample accurate timing (rather than timing based on the computer's hardware clock). // David _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
