[vlc-devel] 2.0.0 and resampling
remi at remlab.net
Wed Mar 7 18:32:35 CET 2012
Le mardi 28 février 2012 23:13:55 Jean-Baptiste Kempf, vous avez écrit :
> The second biggest issue was the CPU used by the resampling (at equality
> to threads delaying display).
So I spent a lof of time measuring all resamplers, and my conclusion is that
there is _no_ regression from VLC 1.1.0.
Here are my peak CPU usage figures (less is better). 027 is basically the cost
of decoding the test MP3 with lavc and outputting it to ALSA plughw:
ugly 027 <-- --no-hq-resampling in VLC 1.1.x and older
band_l 070 <-- default in VLC 1.1.7 and older
SRC 0 385
SRC 1 076
SRC 2 050
SRC 3 027
SRC 4 027
speex 0 037
speex 1 040
speex 2 043
speex 3 050
speex 4 056 <-- default in VLC 2.0.0
speex 5 066
speex 6 073
speex 7 090
speex 8 103
speex 9 172
(Debian i386 builds of SRC and speex).
As we can see, the usage has actually gone _down_ from VLC 1.1 defaults. Not
to mention that I build bandlimited with SSE math on my system, while Debian
builds libsamplerate and libspeex-dsp for plain x87 (to my knowledge).
Ok, in previous versions, you could disable the slow high quality path. You
can still do the same in SRC preferences with zero-hold or linear (if speex is
NOT enabled). High quality was enabled by default and nobody whined.
More information about the vlc-devel