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
loop.
[...]
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
wheel,
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
that
doesn't use a sequencer callback, scheduling notes and and rendering
audio
inside a loop. I can't still observe any problem.
Regards,
Pedro
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.