On 17.02.2017 14:23, Arun Raghavan wrote: > > On Fri, 17 Feb 2017, at 02:34 PM, Georg Chini wrote: >> Hi, >> >> to get even better latency stability of module-loopback, I am still >> working on an alternative >> smoother implementation. I am at the point where I have created a set of >> functions similar >> to the original implementation: >> >> >> /* Create new smoother */ >> pa_smoother_2* pa_smoother_2_new(pa_usec_t window, size_t frame_size, >> uint32_t rate); >> /* Free the smoother */ >> void pa_smoother_2_free(pa_smoother_2* s); >> /* Reset the smoother */ >> void pa_smoother_2_reset(pa_smoother_2 *s); >> >> /* Add a new data point and re-calculate time conversion factor */ >> void pa_smoother_2_put(pa_smoother_2 *s, pa_usec_t time_stamp, int64_t >> byte_count); >> >> /* Calculate the current latency. For a source, the sign must be inverted >> */ >> int64_t pa_smoother_2_get_delay(pa_smoother_2 *s, pa_usec_t time_stamp, >> size_t byte_count); >> /* Convert a time interval from sound card time to system time */ >> pa_usec_t pa_smoother_2_get(pa_smoother_2 *s, pa_usec_t time_stamp); >> /* Convert system time to sound card time */ >> pa_usec_t pa_smoother_2_translate(pa_smoother_2 *s, pa_usec_t >> time_difference); >> >> /* Enable USB hack */ >> void pa_smoother_2_usb_hack_enable(pa_smoother_2 *s, bool enable, >> pa_usec_t offset); >> /* Set user time offset */ >> void pa_smoother_2_set_time_offset(pa_smoother_2 *s, pa_usec_t offset); >> >> >> My question is how I should integrate this with the current code. I see >> two possibilities: >> - Replace the old smoother wherever it is used >> - Add a parameter to daemon.conf (use-alternative-smoother) so that you >> can choose >> between the two implementations. >> Probably the second option is preferable. What do you think? Any better >> idea? > Is there a way to characterise/test how the implementations compare? > Maybe a compile-time/#ifdef selection is sufficient as a first pass, and > then we can figure out how to proceed. I'd imagine we just want one > implementation and not have the complexity of maintaining two. > > -- Arun I have quite a good picture how the two compare in terms of latency reliability for alsa devices. I had implemented it first directly within the alsa code and you can see the results (and also the theory behind it) at : https://www.freedesktop.org/software/pulseaudio/misc/rate_estimator.odt I cannot say how it compares in terms of CPU usage. The current smoother is called fairly seldom but has a lot of loops, while my code is rather simple but is called each time when data is written or read.