[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