[vlc-devel] 2.0.0 and resampling

[Rémi Denis-Courmont]

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
speex10	226
(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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis