Generally you can't mix soft float with hard float compiled binaries and libraries (at least I think pdaXrom doesn't use the new EABI, does it?). You would have to recompile everything for hard floats and I really don't see the point in that. We've been there and done that in the first pdaXrom releases...
The benchmarks I posted on my website are only representative for Cacko and SharpROM - I should have made that one clear.
I think the reason the softfloat benchmark results are roughly on par with the Netwinder float point emulator (NWFPE) is due to the softfloat functions in GCC 2.95.x being generic and not specifically optimized for ARM. NWFPE is using the very same functions from what I know. Add to that the trapping and context switch overhead that's happening in the kernel.
AFAIK the softfloat functions in GCC 3.x used in pdaXrom are more tuned for ARM. The only way to figure that out is checking the sourcecode and re-doing the necessary benchmarks on pdaXrom. I'll do that tonight.
Update: I've updated the benchmark results at http://www.katastrophos.net/zaurus/kernels.../FPE-Benchmark/GCC 3.4.6 has better softfloat code than GCC 2.95.3. It's faster than FastFPE. Like I said, you can still benefit from FastFPE if you use a chrooted Debian / Pocketworkstation, which binaries contain hardware floating point instructions. It's still 3-5 times faster than the regular NWFPE.Anyway, the thread was about the sound quality and audio chip features, so how about that? Anybody feeling brave enough to try my stuff?