MPD: My Setup 2018
UPDATE! Check out my latest post on MPD to see an updated writeup on my MPD setup and usage.
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 "0.0.0.0:6600"
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/mpd.pid"
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 viancmpcpp
. I keep the port configured so I can connect with an android client (see below.) -
An explicit value for
user
andgroup
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"
XF86AudioRaiseVolume
# Decrease volume
"volume-tweak --lower"
XF86AudioLowerVolume
# PLAY KEY
"mpc toggle"
m:0x0 + c:172
XF86AudioPlay
# STOP KEY
"mpc stop"
m:0x0 + c:174
XF86AudioStop
# PREV KEY
"mpc prev"
m:0x0 + c:173
# NEXT KEY
"mpc next"
m:0x0 + c:171
# Muting
"mute-or-not"
XF86AudioMute
-
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 ofnotify-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 192.168.1.103 -p tcp -m tcp --dport 6600 -j ACCEPT
# iptables -A INPUT -s 192.168.1.103 -p tcp -m tcp --dport 8340 -j ACCEPT
# iptables -A INPUT -s 192.168.1.104 -p tcp -m tcp --dport 6600 -j ACCEPT
# iptables -A INPUT -s 192.168.1.104 -p tcp -m tcp --dport 8340 -j ACCEPT
The above rules would allow the hosts 192.168.1.103
and 192.168.1.104
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 new things I can improve. Even config files I don't touch for years can sometimes undergo small changes and yield vast improvements. Until next time!