Bug#738981: Switch to use generic_fpu for ARM

Thomas Orgis thomas-forum at orgis.org
Sun Feb 16 10:46:35 UTC 2014


Sorry for being late to the party, but I have to say that this is a
rather unfortunate situation now. Not using the assembly-optimized
fixed-point ARM code of the arm_nofpu decoder and resorting to the
generic_fpu one (all plain C) will make mpg123 really slow in
comparison. I'm not sure what hardware we are targeting here ... is it
armel with softfloat? With gcc -mfpu=vfp, generic_fpu might be fine,
although using the neon decoder is still preferred on supporting CPUs.

There is no runtime detection in mpg123 for this and at least for the
decision of fixed or floating point decoding, it likely will never be
as that is a very basic decision on the whole decoder code, not just
some optimization. I can imagine combining generic_fpu and neon builds
with run-time detection, but this still assumes a hardware floating
point unit to make sense. We have arm_nofpu and generic_nofpu for the
cases without one.

Something which is possible right now is to produce one libmpg123.so with
the standard build to please users using slow ARM machines who just
want plain 16 bit playback and produce one libmpg123_float.so for people
using beefy machines and who are using audacious as a media player.

Well ... the least would be to offer builds with usage of vfp if
present (I see hints https://wiki.debian.org/ArmPorts that that's an
option, including runtime linker choice). In any case, ARM's a real
mess in that respect. Very hard to produce a build that is optimal for
that wide range of configurations that debian tries to support.

I could implement a conversion step to floating point with the
arm_nofpu decoder. That would make audacious work (although wasting
precision on machines that have hardware floating point, or even NEON)
and have the benefit of the command-line mpg123 still being fast with
16 bit output. A debian build targeting modern floating-point-capable
hardware would use generic_fpu or better the neon decoder to begin with.

Is there preference to have the faster decoder for debian without
floating point hardware?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20140216/10257b07/attachment.sig>


More information about the pkg-multimedia-maintainers mailing list