[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