Re: [fluid-dev] changing audio.period-size

[jean-jacques.ceresa]

Hi Hamish,

The bad new:
From my experience, (as i am using Windows too), using dsound driver (i 
assume you are using this  default driver too) it is not possible to get 
low latency response.
This is inherent to dsound as it require multiples buffers to do its 
jobs. Anyway the big advantage, it allows multiples independant 
applications to use the same
audio card at the same time (dsound doing the mix).

At initialization time, fluidsynth driver set this 2 parameters into dsound:
audio.periods, is the numbers of buffers (default 8), i have tried 4 
minimum with success.
audio.period-size, is the size of one buffer (default 512), like you, i 
have tried 256 minimun with success. We cannot compensate with 
audio.periods as
it function is different.

The good new
Using portaudio driver should enhance seriously latency and problably 
noteOn scheduling precision.

jjc

Le 01/07/2016 09:25, Hamish Moffatt a écrit :
> Is there any harm in reducing audio.period-size on Windows? It's a lot 
> bigger by default on Windows than Mac/Linux. Should I increase 
> audio.periods to compensate?
>
> Background: I have my own timing loops and I'm outputting events by 
> calling fluid_synth_noteon/noteoff() just in time (or with 
> fluid_sequencer_send_now()). However it seems that with the default 
> parameters, notes are only scheduled on 20ms boundaries. If I get the 
> time between my noteOn calls from fluid_sequencer_get_tick() it's 
> always a multiple of 20, even though I'm calling it much more 
> accurately than that. Reducing period-size to 256 helps. Is there a 
> disadvantage, and is there a better way?
>
>
> thanks,
>
> Hamish
>
>
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev