Re: Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
On Tue, Mar 4, 2014 at 2:26 PM, Thomas Orgis <thomas-forum@orgis.org> wrote:
> Am Tue, 4 Mar 2014 11:10:25 -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
>
> 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
Reply to: