Dear ARM porters, Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981 for full context. I've uploaded a patch proposed by Riku that AFAIUI makes mpg123 really slow on all arm targets, while unbreaking it on some others.
As one of the maintainers of the mpg123 without familiarity about the scope of the Debian arm port, I'm rather confused about what's the best way to proceed here, and would need more input. Can someone more experienced please advise? Thanks, Reinhard ---------- 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 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? _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- regards, Reinhard
signature.asc
Description: PGP signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
