> ---------- Forwarded message ---------- > From: Thomas Orgis <thomas-fo...@orgis.org> > Date: Sun, Feb 16, 2014 at 5:46 AM > Subject: Bug#738981: Switch to use generic_fpu for ARM > To: 738...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org