[Top][All Lists]

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

Re: [fluid-dev] fluid_sequencer_send_at ignoring time when not using an

From: Raja Mukherji
Subject: Re: [fluid-dev] fluid_sequencer_send_at ignoring time when not using an audio driver
Date: Tue, 19 Jun 2012 09:17:46 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On Tue 19 Jun 2012 08:09:34 IST, David Henningsson wrote:
On 06/18/2012 01:04 AM, Raja Mukherji wrote:
Sorry, there are things that I don't understand in your pseudocode. For
instance, how is calculated TIME_STEP in the call to
fluid_synth_write_float() ? maybe you wanted to use FRAME_STEP
instead ?

Yup, I meant to write FRAME_STEP instead of TIME_STEP.

On 17/06/12 21:04, Pedro Lopez-Cabanillas wrote:
On Sunday 17 June 2012, Raja Mukherji wrote:
I'm not using
fluid_sequencer_register_client and a callback to add new events,
instead I'm adding events using fluid_sequencer_send_at and then
directly calling fluid_synth_write_float in effectively one large
I have found a working solution for now, by writing my own simple
sequencer (which interleaves calls to fluid_synth_write_float with
direct calls to fluid_synth_noteon, fluid_synth_noteoff, etc).

Well, you have already solved your problem, probably reinventing the
but just to be sure and for the sake of others that would doubt
because of
your claim, I've attached another variation to the metronome example
doesn't use a sequencer callback, scheduling notes and and rendering
inside a loop. I can't still observe any problem.


Ok, the problem can be reproduced in your second example file by setting
"audio.period-size" to 3 * sample_rate (rendering a 3 second block at a
time). After checking the documentation, I see that the range for
"audio.period-size" is 64 - 8192, however I'm not using an audio driver
and there's no such limit mentioned for the fluid_synth_write_float
function. My sequencer is essentially the same as your code, but applies
events to the fluid_synth_t object directly. So it seems that the issue,
if you consider it an issue, applies only to the fluid_sequencer_t
object when used with large period sizes.

The sample timer was designed to avoid these kinds of problems. Make
sure you create the sequencer with new_fluid_sequencer2(FALSE) - i e,
not using the system timer. Together with the seqbind object it will
advance the sequencer automatically when audio is rendered.

// David

I've done that, and that is how it is in Pedro's sample files. I tried using new_fluid_sequencer2(TRUE) to make sure there is a difference and as expected that gives a completely different incorrect result.

reply via email to

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