What Is MPD (Music Player Daemon) and How Does It Work?

MPD (Music Player Daemon) is a server-side music player that runs in the background and plays audio on demand, with no graphical interface of its own. You control it from a separate client program, which can run on the same machine or over the network. It fits situations where you want one always-on music engine — a home server, a Raspberry Pi, or a hi-fi setup — that several devices can share and control at once. It is not a desktop app you double-click to start playing a file.

The client–server split

MPD separates two jobs that ordinary music players bundle together:

• The daemon (server): owns the music library, the audio output, and the playback state. It starts at boot, keeps running, and does nothing visible.
• The client: a separate program that sends commands ("play this album", "skip", "set volume") and displays what's happening. It can connect locally or remotely.

Because the daemon holds the playback state, closing a client doesn't stop the music. You can disconnect from one machine and reconnect from another, and the same track keeps playing. That is the core difference from a desktop player, where quitting the app ends the session.

The site describes MPD as "a flexible, powerful, server-side application for playing music," which matches this model.

What it can play

MPD handles both local files and network sources. According to the project's own keywords, supported material includes:

So a single MPD instance can serve a local FLAC collection and an internet radio stream through the same control interface.

How a session actually works

1. MPD starts as a background service and reads its configuration, including where your music lives and which audio output to use.
2. You connect a client. The client talks to MPD over its control protocol, either on the same host or across the network.
3. You build or browse a queue. The client asks MPD to add tracks, albums, or streams to the current playlist.
4. MPD plays. Audio comes out of the machine running the daemon — not the client. This matters: if MPD runs on a headless server, the sound comes from that server's audio output, not from your laptop.
5. State persists. Pause, skip, or change volume from any connected client; every other client sees the same state.

The practical consequence of step 4 is the most common source of confusion. Controlling MPD from your phone does not route audio to your phone — it routes commands to wherever the daemon and its speakers are.

Clients

MPD itself has no interface, so you always need a client. The project's news section, for example, notes that "myMPD 26.0.0 has been released," referring to one such client. Clients range from terminal-based controllers to web interfaces to mobile apps, and different clients suit different devices — a phone-friendly one for the couch, a keyboard-driven one for a terminal.

When MPD is the right choice

MPD tends to make sense when:

• You want one music library shared across several devices rather than separate copies.
• The playback machine is always on — a server, NAS, or Pi — and you control it from elsewhere.
• You prefer low resource use and a headless setup over a full desktop application.
• You want to keep playing while switching controllers, or have multiple people control the same output.

It tends to be the wrong choice when you want a single self-contained app on one computer, when you need the audio to come out of the device you're holding, or when you'd rather not configure a service and pick a client before hearing anything.

The short version

MPD is a background playback engine plus a control protocol. The daemon plays; clients command. It supports common lossless and lossy formats plus radio and streaming, and it's built for always-on, multi-device, remotely controlled listening rather than single-app desktop use. If that split matches how you listen, MPD is a strong fit; if you want one app that does everything on one machine, a conventional desktop player will be simpler.