> >> > I see. In that case, I'll have to leave the package as it until > >> > something along those lines is implemented. So, I got conversion to float implemented now and tested with the generic_nofpu decoder on x86-64. It _should_ of course work with ARM, too;-) If you'd like to check the current snapshot of mpg123, http://mpg123.org/snapshot/mpg123-20140220132548.tar.bz2 , you hopefull will find that any normal build of mpg123 (unless specifying --disable-float explicitly) now offers all usual formats. As a bonus, I even implemented the 8 Bit A-Law output, which has always just been a placeholder (nobody missed it, apparently). I'd be interested on some timings of mpg123 -t -e s16 test.mp3 mpg123 -t -e f32 test.mp3 with the various builds you'll do for the ARM variants. Best would be running perl scripts/benchmark-cpu.pl src/mpg123 convergence_-_points_of_view/*.mp3 with http://mpg123.orgis.org/convergence_-_points_of_view.tar.gz as reference album, as mentioned on http://mpg123.orgis.org/benchmarking.shtml to be able to compare the performance of the code and machine to others. This yields output like this: #mpg123 benchmark (user CPU time in seconds for decoding) #decoder t_s16/s t_f32/s x86-64 3.39 4.05 generic 6.15 6.01 generic_dither 6.36 5.97 ... or this, with --with-cpu=generic_fpu: #mpg123 benchmark (user CPU time in seconds for decoding) #decoder t_s16/s t_f32/s generic 6.14 6.29 (on a Core2Duo machine). > Yes, you can do that - build several copies of the library and use the > hwcaps / auxv approach to pick the best one for the hardware at link > time. > > >NEON detection may come... but if we have linker selection, that would > >be covered right now. > > Yup. Seconding the second part: Linker selection it is. NEON runtime detection just isn't fun in user code. The bright side: If the multiple builds are setup and tested, I can safely release mpg123-1.19.0 with the changes and we finally have this settled. Alrighty then, Thomas
Attachment:
signature.asc
Description: PGP signature