Your message dated Tue, 9 Apr 2013 11:05:16 +0200 with message-id <[email protected]> and subject line Re: Bug#517976: significantly more cpu usage on armel than before has caused the Debian Bug report #517976, regarding significantly more cpu usage on armel than before to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 517976: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517976 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: mpd Version: 0.14.2-2 Severity: normal Between version 0.13.2-3lenny1 and 0.14.2-2, mpd has gotten much worse at mp3[1] sound playback on armel. It seems to be using a *lot* more cpu. I noticed that when I'm running the stable version, mpd's cpu usage on my thecus while playing a mp3 is often below 1%. With the unstable version, it never gets below 20-30%. This isn't just about CPU load numbers of course. It's about reliably getting clear playback under load without audio glitches caused by the buffer running dry, etc. I can reproduce this at will, on two separate arm machines. They are: turtle: a thecus N2100, with this: Bus 002 Device 002: ID 041e:3040 Creative Technology, Ltd SoundBlaster Live! 24-bit External SB0490 box: a qnap ts-109 with the following cheap usb sound dongle: Bus 002 Device 005: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter 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. I'm still learning toward it being due to floating point, but since mpd has become threaded, arm threading innefficies also seem plausible. -- see shy jo [1] I think ogg is also affected, but I've been testing with mp3s only. [2] armel sucks less, but let's face it: w/o cpu-specific optimised builds, it still sucks :-)
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---Fixed: 0.15-1 thanks from skimming the bug log, I believe the issue was fixed with the two commits mentioned in messages #55 and #60, long ago in 2009 Florian
--- End Message ---
