fluid-dev
[Top][All Lists]
Advanced

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

Re: [fluid-dev] Event Timing in FluidSynth


From: David Henningsson
Subject: Re: [fluid-dev] Event Timing in FluidSynth
Date: Wed, 31 Jul 2013 03:01:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7

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




reply via email to

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