On Tue, Jun 19, 2012 at 10:17 AM, Raja Mukherji <rajamukhe...@gmail.com>wrote:
> On Tue 19 Jun 2012 08:09:34 IST, David Henningsson wrote: > >> >>> 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. > That incorrect result using the system timer with large buffers is officially called here the "drunken drummer" effect :-) OTOH, setting "audio.period-size" to 3 * sample_rate is not possible, because the function fluid_settings_setint() automatically trims the value to the maximum allowed (8192). If you want to test larger buffers, you need to avoid the fluid_file_renderer altogether, but I don't have time to write another test program version. Anyway, I don't see why fluid_synth_write_float() should impose any limit on the buffer size. Regards, Pedro
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
