ldolse,
I just want to applaud your efforts to provide a full out-of-the-box solution for a Linux MPD server.

In early 2008 I set up a small music server based on Intel mini-ITX, running MPD under Puppy Linux 3.0, outputting the audio locally through a Chaintech AV-710 sound card. This budget sound card was claimed to have audiophile credentials when configured so that its Envy 24HT-S chip redirected the main (front) audio outputs to the rear output circuitry, which then took advantage of a the sound card's well-regarded Wolfson D/A converter.
With high expectations I eventually connected this system to a friend's uber-expensive hifi system, but I was disappointed to find how far short the audio quality was compared to their high-end CD transport and DAC.
I now realise I was expecting too much from a budget sound card.

Almost 3 years later, I note with interest that you're using the ESI Juli@ sound card, which the hifi forums seem to constantly recommend these days.
My next foray into computer audio will involve MPD on a server running some form of embedded OS, with a yet-to-be-decided high end USB DAC providing the audio output.

J.Allen wrote:

I'm a bit surprised there isn't a queue of frustrated audio enthusiasts, Linux wannabes, much like myself standing in line to shake your hand.

I'm not surprised - this application appeals to audio enthusiasts/hifi enthusiasts, and such people are not necessarily conversant with Linux.
On the other hand, the average Linux enthusiast is not necessarily an audio enthusiast, and their music requirements are likely to be satisfied by a less complicated and more mainstream music player application.

So we're talking about two minority groups; audio enthusiasts and Linux users, and this application (MPD) is generally known to the rare group of people who overlap those two minority groups!

For visitors to this forum thread confused by what all the hype about Music Player Daemon is about, let me try to explain:

MPD is a music client/server playback system. The main MPD application is the server, which includes a proper database.
Separate client applications, of which there are many available, connect to the server, and control playback.
In the most basic configuration, you can run both the server and a client on the same computer. In this setup, MPD appears little different to any other music player. But things start to get interesting once you separate out the server from the client;

- The configuration that most users seem to employ is with a second "livingroom-friendly" computer used as the client, connecting over the LAN to the MPD server somewhere else in the house. Here the server sends an audio stream to the client, as requested by the client. The client computer acts as both the controller and the audio output device. This can be particularly useful if the client computer is a portable device such as a tablet.

- The second common configuration, my personal preference, is where the the MPD server outputs audio, itself, and the client computer is just a controller. You could use a small tablet computer (any operating system) as the client device, which will effectively then be a "glorified remote control".
The MPD server must have some form of audio card (or external USB DAC) which is connected directly your hifi equipment. Since hifi equipment is typically in a fixed position, portable audio output has no real benefit ...
but it's useful to be able to have the controller portable, particularly if your livingroom listening area opens onto different areas of the house such as the kitchen, for example.

- from there you can start to get really complex with configuration - a third computer can be set up on the LAN purely for audio output. Commercial vendors are starting to refer to this type of device as the "media renderer". This output device is the destination point of your audio output, but the server remains centralised, and the controller (client) also remains separate.

And from there, any number of clients and output devices can all connect to the same server!
Not many people would require this level of complexity, but it shows how powerful the MPD system is.

There are two particular appealing factors of the MPD system: it provides very useful functionality, both in terms of playback configuration and music management, and it's also a good foundation upon which to base a high-fidelity computer-based music system.
So the appeal of MPD is not limited to hifi buffs, but the system appeals particularly to hifi buffs.

For audiophiles who wish to optimise their Linux MPD configuration for audio quality, a major element is to ensure bit-perfect digital output to the sound card or DAC, as such:
i) ensure that MPD will not use its software mixer. In your MPD configuration file, /etc/mpd.conf
make sure that this line is commented out -

Code:

mixer_type "software"

and ii) the "dmix" function of the ALSA audio system should be disabled. Create a new document in Geany with this -

One thing i've allways loved about mpd was the simpleness?!? of configuring and controlling an shoutcast output. I've used this setup for parties as an example, where the controller streams to a number of receiver (In this setup audiophile quality is not the main argument).

Yes, two of the configurations I explained above involve streaming over the LAN, but I used the built-in HTTP streaming
option of MPD, not the ShoutCast streaming option.
I confess that I don't know the relative benefits of each.

Appreciate the votes of confidence/feedback, along with the background on Music Player Daemon for the uninitiated. My initial target audience was people looking to hook this server up to their stereo directly and control it remotely - my favorite remote control is mPad on the iPad, but this project has forced me to learn about many other clients and I must admit I have some new special purpose faves. The setup wizards built into mpdPup follow the best practices Tempestuous mentions regarding disabling dmix, etc and outputting bit-perfect output via whatever audio interface the user chooses.

That said, shoutcast/http out support is compiled in as well. Right now the wizards I've written don't provide a simplified setup for that, but it's simple enough to enable for anyone comfortable with editing mpd.conf. A longer term goal is to expand the wizards to allow different types of outputs. I've also seen hints that some of the mpd devs are working on DLNA and RAOP support, which would provide an exciting addition for higher quality network broadcasting than the current shoutcast/http functionality.

Regarding the take-up, I'm probably also a bit late to the game with mpdPup - as Tempestuous notes, this is probably of interest to a relatively small cross-section of users, and many of those users are using Voyage Linux. I'd actually started on this project a couple years back, but when a Voyage variant dedicated to mpd came out I put things on the back burner. It was only much later when I'd tried Voyage and decided it was still too technical for a typical Windows/Mac user that I came back to this project, since many of Puppy's goals around ease of use coincide with my goals for this derivative.

I've been busy working on the next release, and am quite excited about where it's going. It's using the 2.6.39.4 kernel, which now includes remote control support. So the next update will have out of the box support for any Soundgraph iMon remote control/LCD, and other remote controls will work with minimal effort. I'm also adding two new clients, albumbler and mpd-sima. These are all working quite well to provide automatic DJ/smart shuffle capabilities, especially when combined with the new remote control function - I've already got this all working, just need to fine tune my init and remaster build scripts.

My stretch goal is to add a radio station index. I've found an index which provides access to several thousand stations, I just need to write some scripts to parse the index files to allow users to browse the selection, add them to MPD's playlist folder, and assign them to remote control hot-keys.

I've also seen hints that some of the mpd devs are working on DLNA and RAOP support, which would provide an exciting addition for higher quality network broadcasting than the current shoutcast/http functionality.

That's interesting. In the past I have asked associates of mine with more technical knowledge than I about how and why certain streaming protocols can be "better" than others. I remain dubious about whether some of these protocols are necessarily "better" in a technical sense, though they may be better in the way they include metadata.

I may be wrong, but I believe DLNA/RAOP will allow lossless audio to be transmitted across the network vs. the compressed options that I believe are all that's supported today. LPCM is the DLNA 'standard' for home devices, though other codecs are allowed and I'm not sure how it will be implemented in mpd for now.

There are a lot of DLNA renderers that are more inexpensive than NAIM (built into many new TVs and other media center devices), so hopefully however the patch finally gets implemented it will be vendor agnostic. Anyway it's progress.

I believe DLNA/RAOP will allow lossless audio to be transmitted across the network

True. Compared to some other streaming protocols and proprietary devices that might be considered impressive, but by MPD standards that's no big deal! The built-in HTTP streaming of MPD allows any valid audio format. In this regard, MPD's built-in streaming should be considered native ie. the same standard as the source audio files.

This has ramifications for high-resolution audio files: MPD will happily stream them, but your network might not cope with the data rate, especially over wifi!!
For example I anticipate obtaining at least some of my music in the future as 192kHz/24bit flac files. These might be difficult to stream over wifi, and it might be necessary to have some form of wrapper script which will automatically activate LADSPA to down-sample high-resolution files in streaming output situations.

Thanks for the hint on Streamtuner - I wasn't aware of what that particular app did, though I'd seen it in several puplets. Streamtuner isn't sufficient for my needs as it's unmaintained and doesn't have a cli version, but that led me to a newer project called Streamtuner2. It can be used either from the GUI or the Console, so that meets the requirements for any apps I bundle into this livecd. It doesn't seem to have explicit support for mpd, but that should be simple enough to rectify. Saves me from completely re-inventing the wheel.