<h1 id="title">MPD: My Setup 2018</h1>
<span>Posted: <time id="post-date">2018-04-21</time> | Updated: <time>2020-12-10</time>, <time>2021-01-04</time></span>
<span class="bold">UPDATE!</span> Check out <a href="/blog/listening-to-music-on-linux-with-mpd-part-4/">my latest post on MPD</a> 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!
<h4 id="server">The Server</h4>
<p>The server config has changed just slightly:</p>
<p>Of note, we have:</p>
<li>Binding to port <code>6600</code> as well as a unix socket at <code>/run/mpd/socket</code> - this allows browsing for files outside of your configured music directory via <code>ncmpcpp</code>. I keep the port configured so I can connect with an android client (see below.)</li>
<li>An explicit value for <code>user</code> and <code>group</code> to ensure that the daemon runs as my user and group.</li>
<li>I added an explicit log file location, for sending that off to ELK (for real!)</li>
<li>Replaygain (see <code>man mpd.conf</code> for more details) turned off.</li>
<h4 id="client">The Client</h4>
<p>I'm still rocking <code>ncmpcpp</code> but I've updated the config a bit:</p>
<pre><code>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 = "◆▋"</code></pre>
<p>Not much changed:</p>
<li>The MPD host value now points to the socket, for reasons mentioned above.</li>
<li>Upped the sync interval from 30 to 120 -- MUCH smoother visualizer, which looks awesome to boot.</li>
<li>The visualizer look sports a wider bar, which looks better.</li>
<p>In addition to <code>ncmpcpp</code>, I'm also using <a href="https://f-droid.org/en/packages/org.gateshipone.malp/">M.A.L.P.</a> to remotely control my MPD server from my android device.</p>
<h4 id="controls">The Controls</h4>
<p>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:</p>
<li>A volume "wheel" that can turn it up or down.</li>
<li>A volume mute button</li>
<li>Standard track controls: play/pause, stop, previous track, next track.</li>
<p>Enter <code>xbindkeys</code>, which has a simple configuration file at <code>~/.xbindkeysrc</code> in which you enter each binding:</p>
<pre><code># Increase volume
# Decrease volume
# PLAY KEY
m:0x0 + c:172
# STOP KEY
m:0x0 + c:174
# PREV KEY
m:0x0 + c:173
# NEXT KEY
m:0x0 + c:171
<li>The <code>volume-tweak</code> 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...</li>
<li>In truth, my actual <code>.xbindkeysrc</code> is all wrappers - the core commands are the same as above but I've wrapped them to include the usage of <code>notify-send</code> so I can get desktop notifications from them.</li>
<li>As with <code>volume-tweak</code>, <code>mute-or-not</code> 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.</li>
<p>With a little bit of configuration, I now have working music control keys and they do in fact work quite slick-ly!</p>
<h4 id="speakers">The Speakers</h4>
<p>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.</p>
<h4 id="bonus">The Bonus!</h4>
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 <code>/etc/mpd.conf</code>:
name "My HTTP Stream"
In the above snippet, I've declared a new output of the <code>httpd</code> type and given it a pretty generic name. It'll run on port <code>8340</code> 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 <code>mpd --version</code> to see what your version supports.
Of course, I can't recommend just running this wide open; it's pretty simple to add some <code>iptables</code> rules to limit access to specific hosts that you want to have access to your stream:
<pre><code># 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 <code>192.168.1.103</code> and <code>192.168.1.104</code> to reach both your HTTP stream on port <code>8430</code> (TCP) as well as connect directly to MPD over port <code>6600</code> (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.
<p>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 <code>mpc</code> or some other MPD client:</p>
<pre><code>$ mpc disable "My HTTP Stream"</code></pre>
<h4 id="the-end">The End?</h4>
<p>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!</p>