On 08.02.2015 20:30, Georg Chini wrote: > On 08.02.2015 19:54, Alexander E. Patrakov wrote: >> 01.02.2015 03:43, Georg Chini wrote: >>> + /* Minimum number of adjust times + 1 needed to adjust at 0.75% >>> deviation from base rate */ >>> + min_cycles = (double)abs(latency_difference) / u->adjust_time / >>> 0.0075 + 1; >>> + >>> + /* Rate calculation, maximum deviation from base rate will be >>> less than 0.75% due to min_cycles */ >>> + new_rate = base_rate * (1.0 + latency_difference / min_cycles / >>> u->adjust_time) + 0.5; >> >> What's the aim here with min_cycles? Why not just clamp new_rate >> post-factum to 0.75% vicinity of base_rate, as this is done in the 2â?° >> case? >> > Without min_cycles you will far more often hit the 2 â?° limit and when > you are approaching the > base_rate. This seriously disturbs the regulation. The goal was to get > out to 0.75% as quick as > possible while approaching the base rate cautiously (with a weak > regulator when latency is far off). > Also without min_cycles you see the rates hopping up and down (due to > the 2â?° limitation), you do > not see a (more or less) continuous rate function. Doing what you suggest would give you 0.75% as long as the latency is more than one cycle off - but from 0.75% rate deviation you need at least 4 steps to go back to the base_rate with the 2 â?° restriction, so you would seriously over-regulate. > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
