On Tue, Mar 4, 2014 at 2:26 PM, Thomas Orgis <thomas-fo...@orgis.org> wrote: > Am Tue, 4 Mar 2014 11:10:25 -0300 > schrieb Felipe Sateler <fsate...@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 > > Yes, a difference, but aguably a lot less than comparing VPU code to > NEON. With the feature to produce float output from all decoders, it is > your (debian's) option to prefer decoding speed by building a libmpg123 > with arm_nofpu and use it on armhf machines without NEON via the > library loading mechanism. Or you decide for offering "proper" floating > point output that needs some 25-50 % more CPU time. > > I am even more interested in a comparison with the runtime of madplay > in that configuration. Perhaps its fixed-point math with 24 bit output > is still faster than using the VFP with mpg123. Of course, I'd be > interested to know if that's not the case (mpg123 rulez!;-). But if it > is, it wouldn't totally surprise me.
madplay -d -o null: convergence_-_points_of_view/*.mp3 &> /dev/null 130.22s user 1.88s system 93% cpu 2:21.91 total That's with the following mad: MPEG Audio Decoder 0.15.1 (beta) Copyright (C) 2000-2004 Underbit Technologies, Inc. Build options: NDEBUG FPM_ARM ASO_IMDCT ASO_INTERLEAVE1 ID3 Tag Library 0.15.1 (beta) Copyright (C) 2000-2004 Underbit Technologies, Inc. Build options: NDEBUG madplay 0.15.2 (beta) Copyright (C) 2000-2004 Robert Leslie Build options: AUDIO_DEFAULT=audio_alsa ENABLE_NLS This is the madplay straight from raspbian, not sure if some other configure flag was to be tested. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org