[pulseaudio-discuss] Alternative smoother implementation

Georg Chini georg at chini.tk
Fri Feb 17 13:43:55 UTC 2017

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 :


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.

More information about the pulseaudio-discuss mailing list