Am Sun, 16 Feb 2014 12:14:46 -0500 schrieb Reinhard Tartler <siret...@gmail.com>:
> Thomas, in libavcodec, we "solve" (or rather, workaround, depending on > the PoV) this problem by compiling the libraries multiple times A sane approach. Runtime code selection in each application can be stretched beyond the boundary of it being fun quickly. > ... > be possible to do something like this for mpg123 as well? This would > then require to compile > > /usr/lib/arm-linux-gnueabi/libmpg123.so.0 > for different flavors. However, we would need to make sure that > /usr/bin/mpg123 works with any of them. That would certainly work and is what I imagined. If this offers link-time choice of fixed point, vfp or neon, I'd be overly happy for avoiding headache over making runtime choice inside one build (which seems rather impractical). > I'm wondering if this pattern > wouldn't work for mpg123, but I'm not familiar enough with the > codebase to say if this would work. Can you please comment? I don't see am obvious problem. As long as basic ABI fits (also regarding floating point args), this should work as well as libavcodec. The mpg123 binary queries the library for things like format support and decoder engine and one build can work with arm_nofpu or generic_nofpu (arm-linux-gnueabi), generic_fpu (arm-linux-gnueabi/vfp) and arm_neon (arm-linux-gnueabi/neon/vfp/). I suppose the gnueabihf variants need an separate build for the changed ABI of floating point arguments (?). When setting up the environment to use a specific libmpg123, one should see an effect in the output of mpg123 --list-cpu Just build mpg123 several times, with proper CFLAGS for -march and friends and matching --with-cpu for configure. You can pick which mpg123 binary to use, I suggest the most universal one. In the mpg123 binary itself, there is no assembly code affected by the --with-cpu switch and the performance-relevant bits are in libmpg123. Same for the other helper applications (mpg123-id3dump, mpg123-strip). The only issue still present would be that the most basic libmpg123 still misses floating point output format for audacious. But my guess is that you wouldn't use that player on a system without floating point hardware. As I said, I can change that, for the sake of completeness adding a bit of code converting from 16 bit to 32 bit float (and 24 and 32 bit integer) in the output buffer. The only remaining difference between the libraries would be performance and accuracy of output. Were you aware of the --enable-int-quality flag to configure? Yet another set of decoders being a bit slower but doing better rounding to 16 bit integers;-) In any case, you might want to check out mpg123's tests to verify that your various builds decode properly: svn co svn://svn.orgis.org/mpg123/test mpg123-test cd mpg123-test make # build helper programs (rms computation) perl compliance.pl /path/to/mpg123 This makes a basic MPEG ISO compliance test, comparing decoder to reference output (see http://mpg123.org, after scrolling down a bit). Disclaimer: If anything does not work as I just promised, this is a bug and will be addressed;-) Alrighty then, Thomas
signature.asc
Description: PGP signature