Hello, > > what's so bad about probing at runtime?? (if done correctly of course :) > > That was written under the wrong assumption that you try to work around a bug > in speex. But there is actually no bug, just an incorrect API usage in > PulseAudio, strictly speaking, even in the non-fixed-point case. huh? > on x86/amd64 given s16 input and speex compiled without FIXED_POINT. The > reason I am asking is based on reading the speex source and some well-known > facts: > > * outside of the JACK world, floating-point samples are uncommon; some PA modules use float, and the application/client might use float > * with FIXED_POINT undefined, the first thing that > speex_resampler_process_int() does is to fill in the "x" array, which is > declared as "spx_word16_t *x", which expands to "float *x" (i.e. converts > samples to float), and then proceeds to speex_resampler_process_native(); spx_word16_t is a lovely typedef for a float > * when PulseAudio starts from s16 samples and decides to use the speex-float > resampler via speex_resampler_process_float(), it has to convert s16 to float > first anyway; yes, this is handled explicitly in PA's sconv code (and there are optimizations for SSE and NEON) doing something like float *dst=...; int16_t *src=...; *dst = *src; as observed in speex's _process_int() when compiled with FIXED_POINT #undefined is not a good idea (performance wise) > * it should not matter who converts s16 to float and back - speex or > PulseAudio. it does, PA can do better > So the proposal is: after a benchmark, kill the speex-float family of > resamplers and make it an alias of speex-fixed on all platforms (not just on > ARM) for compatibility. speex is supposed to be compiled with FIXED_POINT undefined, that is the 'default' configuration on most systems; so speex works with float natively and (costly) converts s16 to float internally if necessary therefore the default resampler in PA is float-1 and we convert s16 to float using sconv (which is pretty cheap, on SSE and NEON) I have not checked audio quality float vs. fixed some old results I have sitting around ARM Cortex-A8, TI DM3730 @ 1 GHZ, gcc-linaro 4.6, speex with NEON patch and compiled for floating point this the time in usec for converting 1 sec audio; columns (x) are for different ratios (3) 16000 -> 48000 (4) 32000 -> 48000 (5) 44100 -> 48000 (6) 48000 -> 16000 (7) 48000 -> 32000 float speex-float-0 244049 254090 410431 183777 208527 float speex-float-1 287354 294861 301880 175690 264252 float speex-float-3 683045 465271 495545 349732 555481 float speex-float-7 930664 889618 1373138 781769 1069061 float trivial 972809 1226593 995636 339997 898194 float src-linear 455963 464508 490814 437317 536163 float src-sinc-fastest 459565 462586 496368 577454 434021 float src-sinc-medium-quality 454834 467682 642304 381592 430115 s16 speex-fixed-0 379944 394593 527587 283386 318298 s16 speex-fixed-1 416473 436401 451111 477662 372162 s16 speex-fixed-3 587738 604034 874023 421630 543090 s16 speex-fixed-7 1242645 1033325 1519623 852295 1182068 s16 trivial 926270 1015777 1066528 324401 636840 s16 ffmpeg 723023 604553 869476 503754 594849 same for i7-970 @ 3 GHz 64-bit float speex-float-0 29805 41759 109823 19529 33292 float speex-float-1 40288 35410 131886 24464 33816 float speex-float-3 60871 62089 212634 48750 53208 float speex-float-7 97132 99978 447325 93265 109369 float trivial 38604 38853 37175 16705 27732 float src-linear 52791 50727 58739 20928 36922 float src-sinc-fastest 524501 531380 540299 434588 502243 float src-sinc-medium-quality 1054445 1056684 1183020 968456 1016723 s16 speex-fixed-0 36327 29911 109888 23129 37487 s16 speex-fixed-1 34938 43595 129149 28608 39536 s16 speex-fixed-3 62584 57430 217398 51916 62352 s16 speex-fixed-7 101670 98314 444393 100910 99825 s16 trivial 41626 36157 38977 27114 26112 s16 ffmpeg 57997 59671 66401 57464 62370 p. -- Peter Meerwald +43-664-2444418 (mobile)
