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

[Felipe Sateler]

On Tue, Mar 4, 2014 at 2:26 PM, Thomas Orgis <thomas-forum at orgis.org> wrote:
> Am Tue, 4 Mar 2014 11:10:25 -0300
> schrieb Felipe Sateler <fsateler at 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