MPD: My Setup 2018

Posted by Hristos T. on 2018-04-20, under the category GNU/Linux
Tags: music, mpd

UPDATE 2018-04-27: Of course not even a week after I posted this, I've made yet another tweak -- see the Bonus section at the end of the entry for more details.

I figured it was time for a follow-up to my previous entries on MPD that describes the current state of my setup with all of its evolutions. Here we go!

The Server

The server config has changed just slightly:

music_directory       "/home/hristos/music"
bind_to_address       ""
bind_to_address       "/run/mpd/socket"
playlist_directory    "/home/hristos/music/mpd/playlists"
db_file               "/home/hristos/music/mpd/mpd.db"
pid_file              "/home/hristos/music/mpd/"
state_file            "/home/hristos/music/mpd/mpdstate"
log_file              "/home/hristos/music/mpd/mpd.log"
user                  "hristos"
group                 "hristos"
restore_paused        "yes"
replaygain            "off"

audio_output {
        type    "pulse"
        name    "MPD"
        server  "localhost"

audio_output {
    type    "fifo"
    name    "Visualizer"
    path    "/tmp/mpd.fifo"
    format  "44100:16:2"

Of note, we have:

  • Binding to port 6600 as well as a unix socket at /run/mpd/socket - this allows browsing for files outside of your configured music directory via ncmpcpp. I keep the port configured so I can connect with an android client (see below.)
  • An explicit value for user and group to ensure that the daemon runs as my user and group.
  • I added an explicit log file location, for sending that off to ELK (for real!)
  • Replaygain (see man mpd.conf for more details) turned off.

The Client

I'm still rocking ncmpcpp but I've updated the config a bit:

mpd_host = "/run/mpd/socket"
visualizer_fifo_path = "/tmp/mpd.fifo"
visualizer_output_name = "Visualizer"
visualizer_sync_interval = "120"
visualizer_in_stereo = "yes"
visualizer_type = "spectrum"
visualizer_look = "◆▋"

Not much changed:

  • The MPD host value now points to the socket, for reasons mentioned above.
  • Upped the sync interval from 30 to 120 -- MUCH smoother visualizer, which looks awesome to boot.
  • The visualizer look sports a wider bar, which looks better.

In addition to ncmpcpp, I'm also using M.A.L.P. to remotely control my MPD server from my android device.

The Controls

Here's where things get interesting. I recently bought a keyboard with some music control buttons on it and I wanted to actually be able to use these (it's a Logitech G610 if you are curious about the exact keys/keyboard.) In all I would need to set up bindings for:

  • A volume "wheel" that can turn it up or down.
  • A volume mute button
  • Standard track controls: play/pause, stop, previous track, next track.

Enter xbindkeys, which has a simple configuration file at ~/.xbindkeysrc in which you enter each binding:

# Increase volume
"volume-tweak --raise"

# Decrease volume
"volume-tweak --lower"

"mpc toggle"
    m:0x0 + c:172

"mpc stop"
    m:0x0 + c:174

"mpc prev"
    m:0x0 + c:173

"mpc next"
    m:0x0 + c:171

# Muting
  • The volume-tweak command seen above is actually a wrapper script that sets the Pulse Audio sink volume level - I wrote it so that I'd have a way to seamlessly control the volume of my bluetooth speaker if it was connected. Perhaps I'll go into details about this in another entry...
  • In truth, my actual .xbindkeysrc is all wrappers - the core commands are the same as above but I've wrapped them to include the usage of notify-send so I can get desktop notifications from them.
  • As with volume-tweak, mute-or-not is another wrapper designed to do the right thing if my bluetooth speaker is connected or not, as well as send a desktop notification about the current status.

With a little bit of configuration, I now have working music control keys and they do in fact work quite slick-ly!

The Speakers

Nothing has really changed with my speaker setup; I'm still using both my laptop speakers as well as some external bluetooth speakers. What has changed is how I interract with them, specifically the wrapper scripts for volume and muting that I touched upon above. Details about them might come in a future entry.

The Bonus!

Wouldn't it be great if we could broadcast our MPD via HTTP? Yeah? I agree! To that end, I added the below to the bottom of my /etc/mpd.conf:

audio_output {
  type     "httpd"
  name     "My HTTP Stream"
  port     "8340"
  encoder  "vorbis"
  format   "44100:16:1"

In the above snippet, I've declared a new output of the httpd type and given it a pretty generic name. It'll run on port 8340 and I've selected vorbis as my encoder because it's a good, Free encoder and it is supported on modern browsers. MPD supports a wide variety of encoders, run mpd --version to see what your version supports.

Of course, I can't recommend just running this wide open; it's pretty simple to add some iptables rules to limit access to specific hosts that you want to have access to your stream:

# iptables -A INPUT -s -p tcp -m tcp --dport 6600 -j ACCEPT
# iptables -A INPUT -s -p tcp -m tcp --dport 8340 -j ACCEPT
# iptables -A INPUT -s -p tcp -m tcp --dport 6600 -j ACCEPT
# iptables -A INPUT -s -p tcp -m tcp --dport 8340 -j ACCEPT

The above rules would allow the hosts and to reach both your HTTP stream on port 8430 (TCP) as well as connect directly to MPD over port 6600 (TCP.) This is just the right thing to do when you are broadcasting services on your machine, and it's not at all hard to do.

This isn't seen above as part of the 'whole' MPD config file because it does add some CPU overhead. Depending on the machine it might not be feasible due to resource constraints. At any rate it's pretty easy to switch on and off via mpc or some other MPD client:

$ mpc disable "My HTTP Stream"

The End?

I'm quite happy with my setup, but am of course always on the lookout for improvements. Even config files I don't touch for years can sometimes undergo small changes and yield vast improvements. For now I'm glad to smooth out