Music Player Daemon (MPD) - v0.16.2

[shadowcode]

(04-12-2011 02:12 PM)fsmit Wrote:  After experimenting a little I got the 96Khz Flac files to work, by commenting out the mixer type settings:
# format "44100:16:2"

I assume it downsamples the 96Khz files, and not in a very good way.
Also I have been playing a little with the buffer settings in the mpd.conf file, and a few 24bit FLAC files play OK when the bitstream is relatively low (around 1500 kps), but above that the sounds starts skipping. Maybe it is hitting the maximum CPU capacity of the A-100, or it is not very efficient in decoding...

I dived into MPD's codebase to see if the "format" property was mandatory now (since it showed up in AlanH's config file). It looked like it was, but after some digging it seems that it acts as an override that the output plugin can modify if necessary, as expected. However, I can't tell if this is implemented correctly in the audio output plugin since the data travels throughout MPD and can change quite a lot between the plugin's initialization and when it's actually told to start working. Could very well be that something is broken in MPD itself, or AlanH's plugin. If it still stutters when you force the format field to "96000:24:2" (it would probably only play the 24-bit 96Khz files, but hey, it's for testing) then it'd seem that the A100 series hardware just doesn't cut it.

Finally, it could be that the decoder just can't decode fast enough. Alternatively, if MPD has to do any bit re-ordering or other magic, that as well could be the bottleneck. Personally, I can't really make an educated guess here because I'm not familiar with the limitations of MIPS or SMP's engine. I vaguely remember AlanH saying in some thread that the A110 probably wouldn't cut it. He's probably right.

When I'm playing an ALAC file (which is decoded by ffmpeg afaik), I see about 70%-80% CPU usage. What do you guys see when it's playing a 24-bit 96khz file? (make sure you check before playing as well to see if the CPU is idle'ish to begin with).

If it's all maxed out (99%) then it might mean that the software (format decoder) can't keep up. If it's lower than that, it might mean that the hardware can't keep up. Even then those numbers don't mean a lot if you can't tell what the software is doing... (profiling tools would be nice).

Either way, there's not much I can do I'm afraid. I've compiled both MPD and libflac as optimal (to my knowledge) as possible. I can dump the --configure flags for MPD here, but afaik we're still using AlanH's libflac (which gave for some reason better results than my version, probably a version difference as we compiled to the same flags).

---

Finally, regarding Last.fm, check the MPD forums/newsgroups. This is an MPD feature and afaik there's nothing we can do on how this behaves.
According to the Last.FM API spec:

Quote:You will need to periodically pull on this XSPF service as it will provide content in small chunks. We recommend you prefetch a new XSPF before reaching the end of the last.

.
The guys at MPD might reason that it's up to the MPD clients to provide this functionality, but I suppose you can always file a feature request.