[vlc-devel] 2.0.0 and resampling

Jean-Baptiste Kempf jb at videolan.org
Wed Feb 29 16:56:44 CET 2012


On Wed, Feb 29, 2012 at 03:06:02PM +0100, Rémi Denis-Courmont wrote :
> It's definitely going to be slow on ARM, unless NEON is used (not just
> VFP).

Slow on G5, Atom, on P4 too, but also on C2D with mp3.


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

Sssssh.... Don't wake up Mans! :)

> > 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.

Ok.

> >  - 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.

Are they exactly the same?

What about zero_hold quality? The Computational power seems negligible.

> > 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.

Maybe I did less testing on Linux (that is sure, actually).

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

Atoms and p4 and other smaller machines are at a loss too.
And even for a C2D, spending more time on audio than on video feels
weird.

Best regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device



More information about the vlc-devel mailing list