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 question. 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, Thomas
Attachment:
signature.asc
Description: PGP signature