On 2009/03/03 11:12, Joey Hess <jo...@debian.org> wrote: > My first guess is that something has been rewritten and is using floating > point, at which of course, arm sucks[2]. Grepping for "float" in the new > source > tree certianly turns up a dozen more than in the old. > > pcm_resample_libsamplerate.c looked particularly likely, at a > guess. But configuring --disable-lsr didn't help. Nor did trying > all the samplerate_converter settings, much.
The libsamplerate code hasn't changed except for cleanups. This is where most MPD installations suck most of their CPU. The fallback algorithm (pcm_resample_fallback.c) is fast, but its quality is horrible. > I'm still learning toward it being due to floating point, but since > mpd has become threaded, arm threading innefficies also seem > plausible. I don't think so. There are very very few places in MPD where floating point is actually used, e.g. libsamplerate (libsamplerate doesn't support fixed-point or integer arithmetics), and that hasn't changed. My guess is that you're using software volume. Since mp3 files are now decoded in 24 bit (because libmad provides 28 bit samples, and we're now throwing away 4 bits instead of 12), the software volume code has to revert to 64 bit integer operations - and this is quite expensive on 32 bit CPUs. For i386, mpd.git (0.15~git) contains an assembly version (simple imul with 64 bit edx:eax result, gcc is too dumb for generating this obvious solution) - other architectures might still suffer. If you're using software volume, try to force MPD to use 16 bit samples internally (audio_output_format "44100:16:2" in mpd.conf) - this conversion is performed directly after the decoder, before anything else is done. Another idea: set software volume to 100%, making it a no-op. Is there any chance you can get me an oprofile report? Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
