[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

Am Tue, 4 Mar 2014 16:25:17 -0300
schrieb Felipe Sateler <fsateler@debian.org>: 

> >> #decoder        t_s16/s t_f32/s
> >> ARM     86.26   90.66
> >> generic 102.80  100.06
> >> generic_dither  121.10  100.84

> madplay -d -o null: convergence_-_points_of_view/*.mp3 &> /dev/null
> 130.22s user 1.88s system 93% cpu 2:21.91 total

Interesting. So the VFP is not that bad: You get superior output (not
noticeably, but measurable in the digital domain) from mpg123's generic
decoder in about 75 % of the decoding time.

The lower-quality 16 bit integer decoder of mpg123 is considerably
faster. So, on a armel system without VFP, it makes sense to employ
libmad to achieve 24 bit accuracy with reasonable CPU cost, if you
insist on that accuracy. But with VFP, using mpg123 gives you full 32
bit floating point output with less CPU load. For NEON, it's not even a

I think I can live with that situation;-) both MAD and mpg123 achieve
their goals. MAD gets the best precision out of integer math, mpg123
offers something faster everywhere, possibly with less, but also
possibly with more (irrelevant, 24 bit is _really_ enough) precision.

One might also benchmark a decoder based on ffmpeg, which has both
fixed-point and floating-point decoders, but I don't have a good
command line for that at hand (used mplayer -ac mpg123 and mplayer -ac
ffmp3[float] in the past). Anyhow, leaving scope here. I should get
going and release mpg123 1.19.0 .

> This is the madplay straight from raspbian, not sure if some other
> configure flag was to be tested.

Optimizing for speed vs. quality might be an option ... but that's
somehow missing the point of preferring libmad.

Alrighty then,


Attachment: signature.asc
Description: PGP signature

Reply to: