[pulseaudio-discuss] [PATCH 0/3] resamplers

[Alexander E. Patrakov]

04.08.2014 19:05, Peter Meerwald wrote:
> Hello Alexander,
>
>>> my goal would be to establish libavresample as the new default resampler and
>>> drop the ffmpeg code copied into PA currently; don't worry, this would be
>>> further work based on the feedback received :)
>
>> This conflicts with my goal of writing and getting a rewindable
>> resampler into pulseaudio.

First, sorry for the very harsh reply.

>
> ok, so general direction is not undisputed :)
>
> do you know if libavresample can do rewind?
>
> do you oppose the present patches to split up resampler.c and add new
> resamplers? nothing would prevent yet another resampler
>
> probably different applications need different resamplers, i.e. fast vs.
> correct
>
> currently, speex and ffmpeg are kind-of default:
>
> speexdsp is largely unmaintained, very recently there seems to be some
> activity [0]; speex has SSE and NEON code path
>
> ffmpeg code is copied into the PA repo and has been superceeded by
> libavresample
>
> libavresample has AARCH64, NEON and SSE/AVX codepath, although only
> AARCH64 (!) has SIMD resampling code (yet)
>
> libavresample might be a good basis for general purpose resampling with
> a good infrastructure for architecture specific optimization
>
> regards, p.
>
> [0] https://git.xiph.org/speexdsp.git
>

OK, now I see what you are after. Let me answer point-by-point.

First, libavresample cannot rewind. There is currently no open-source 
rewindable resampler. Just look at the header. There is nothing that 
could save and restore the delay buffer in avresample.

As for the current patch to split up resampler.c (1/3 in your series), I 
don't have any inherent objection to its intent. However, I should look 
more closely before I can say whether its content is good. Will do that 
today.

As for adding _any_ new resamplers, well, I would like to see the 
justification in the commit message for each new resampler. Otherwise 
we'll end up with the equivalent of GNOME 1 situation with clocks.

For libavresample, you have already provided a good justification 
(upstream deprecation of the ffmpeg resampler + SIMD addition) in the 
e-mail I am replying to, please copy it into the commit message. Still, 
I have to look at the patch more thoroughly.

Maybe the end result for the "rewindable resampler" quest will be 
something based on libavresample - but then we'll have to either 
maintain it indefinitely or submit our modifications upstream (where 
they will be likely rejected, as "not needed for libav").

For soxr, I have not seen such justification yet, and thus currently 
have a slight objection to its addition.

Anyway, I think that the task of objectively testing the resampler speed 
and quality also needs to be done, in order to provide such 
justifications. Please see 
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html 
for the formulation.

Feel free to come to the Plumbers conference and discuss it there if we 
don't reach any conclusion before that.

-- 
Alexander E. Patrakov