[vlc-devel] 2.0.0 and resampling

[Rémi Denis-Courmont]

On Tue, 28 Feb 2012 22:13:55 +0100, Jean-Baptiste Kempf <jb at videolan.org>
wrote:
> It seems to depend a lot on the platform and the CPU,

Any floating point-intensive task depends a lot on the compilation flags
and the architecture. It is certainly much faster with SSE enabled (that is
to say if the library is compiled with SSE enabled).

It's definitely going to be slow on ARM, unless NEON is used (not just
VFP).

> but in many
> situation, the audio decoding took more that the video one.

You don't typically postprocess the video. Scaling is done in hardware in
that case.

It is a design bug that VLC needs to resample all the time.

> There are many work-arounds, namely:
>  - removal of libsamplerate and speex_resampler plugins

Personally, I don't mind the ugly resampler, but a number of people claim
it sounds awful.

>  - removal of libsamplerate plugin
>  - lowering of libsamplerate quality to linear or zero_hold.

It might be my ears, but I found aliasing unbearable with the old VLC
linear resampler, while I can hardly perceive any with the remaining ugly
resampler. And anyway, I do not see the point in using SRC then, since VLC
supports or supported the same algorithm natively.

> The speex_resampler plugin does not work on Win32, with both outputs,
> for high sampling files (FLAC 24/96, 24/192 and such).

Meh? These things are purely computational. It cannot work on Linux and
not work on Windows if compiled with the same parameters and running with
the same output rate.

> And it seems the libsamplerate plugin has issues with low samplerates in
> the medium quality mode.

> This is not unexpected for a 2.0.0. But how do we improve this for
2.0.1?

Compile SRC for Pentium III and fall back to ugly on pre-SSE processors.

-- 
Rémi Denis-Courmont
http://www.remlab.net/