[pulseaudio-discuss] [PATCH 0/4] Add support for libsoxr resampler

Andrey Semashev andrey.semashev at gmail.com
Wed Nov 12 23:32:09 PST 2014


On Thu, Nov 13, 2014 at 8:33 AM, David Henningsson
<david.henningsson at canonical.com> wrote:
>
>
> On 2014-11-11 22:39, Andrey Semashev wrote:
>>
>> In short, libsoxr is almost always faster than speex, and introduces much
>> less distortions. Its passband frequency is slightly lower than speex
>> though, and it can add a delay up to 20 ms in some cases.
>
>
> I'm interested in knowing more about the delay. What are "some cases"?

"Some cases" means some sample rate combinations. In my tests I
measured the delay of the resampler, and it was ~20 ms max. I don't
have the results accessible now, I'll add them tonight to the results
page.

BTW, the test code is available here:

https://github.com/lastique/src_test

> I can think of at least two scenarios where this means trouble:
>
>  * VOIP, where you need as low latency as possible, adding 20 ms more is not
> that great
>
>  * Lip-sync, the limit is about ~50 ms, and thus 20 ms is quite a bit of
> that budget

Yes, for real time communication this can be a nuisance, although in
this use case 20 ms usually isn't noticable and is exceeded by network
and other components latency. If you also have video exchange, you
should take into account its own delay, and it can easily exceed that
amount too.

I can add that the delay can be much more critical for real time
recording with monitor, which is used by musicians. Hardcore gamers
also strive for minimum latency, although I'm not sure if the
resampler delay is significant in this case (AFAIK, human reaction
time is hundreds ms anyway [1]). Anyway, if delay is critical, soxr is
probably not the best choice.

> The second problem could be solved if soxr could tell us the delay and we
> could account for it. Is this possible? (I skimmed through the patches but
> did not find anything related)

The library offers the soxr_delay() function that returns the current
delay. I suppose, it should give the result that is needed except at
the very start, when the resampler is filling. I did not use that
function in my patches because there seems to be no API in PA to query
the resampler delay.

[1]: http://enterthesingularity.blogspot.ru/2010/04/latency-human-response-time-in-current.html


More information about the pulseaudio-discuss mailing list