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

[Riku Voipio]

> ---------- Forwarded message ----------
> From: Thomas Orgis <thomas-forum at orgis.org>
> Date: Sun, Feb 16, 2014 at 5:46 AM
> Subject: Bug#738981: Switch to use generic_fpu for ARM
> To: 738981 at bugs.debian.org
> 
 
> 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. 

- snip-

> 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.

If is indeed the case that doing runtime detection of float/fixed code
is not feasible, then it might make sense to provide separate
libmpg123_float.so and libmpg123.so (on armel).

Applications needing flaots would then be linked against libmpg123_float.so
and all others against plain libmpg123.so.

This would mean that audacious would be slow on non-fpu hardware, but
people could still use fast command line mpg123. Which I guess is what
most people with slow non-fpu hardware would do anyways.

Now, if audacious is the only application that need floats, a more
brutal approach could be acceptable:

on armel: ship audacious-plugins without libmpg123 support, and libmpg123
as fixed point for other applications.

on armhf, ship libmpg123 as floats, with runtime autodection of NEON.

This leaves in limbo only on rasberry and others who have vfp but
no NEON. It would be interesting to hear what's the performance of
libmpg123 compiled with different options on rasberry to make sense
what would be the optimal solution for raspbian.

> 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?

There is as many preferences as there is debian developers, I'm afraid.
My primarily preference is that binaries in debian work. Which with
previous state of libmpg123 and audacious was not the case - on any
hardware.

Riku