Stream MPD audio on the local network (and get MPD working on Windows)

[sylsau]

I thought I would share my experience in the case it could be of help to others.

I have a Raspberry Pi attached to the main speaker of my living room. I have 2 computers, a Linux one and a Windows one, which have MPD installed, both using the same synced library.
Here's what I had to do to get the client to receive streams from my machines.

Install MPD on Windows... but on Linux

I couldn't get MPD to work properly on Windows natively.
Using WSL 2, you can easily run an Ubuntu system inside Windows and hence get all of the perks of MPD on Linux without the Windows hassle. Cygwin is a terrible mess that should be avoided.

From my experience, using latest WSL 2 and latest Ubuntu LTS:

• the soundcard layer is handled with a 'pulse' output, but it's buggy
• I use a terminal client (ncmcpp) which works flawlessly. I do not know how GUI client fare on WSL2, but my understanding is that it should be possible
• you can access Windows file from WSL (you may or may not need to edit /etc/fstab)
• httpd streams work great, which I use to get sound anywhere on the local network

To control MPD you can also use a Windows client (like Cantata), and connect to localhost:6600 without problem. As sound may not be optimal through ALSA/Pulse, you'd have to use a player (like VLC) to read directly from the HTTP stream. It's a good way to have MPD work on Windows.
You could also of course use any other client on your local network, like MALP on Android, provided your port are set up correctly.

Streaming from MPD on WSL to the local network

To connect to an httpd audio stream from MPD on WSL, here's what you have to do.
To communicate with the outer local network, you need first and foremost to open a port on your Windows firewall. Assuming we're using port 8000 with httpd, type the following in an elevated PowerShell console:

> netsh advfirewall firewall add rule name="MPD WSL http stream" dir=in action=allow protocol=TCP localport=8000

Inside Windows, WSL gets assigned a particular IP adress. We need to create a bridge between the Windows localhost and the WSL IP. The IP identifying WSL on Windows can be found using the following in a PowerShell console:

> wsl.exe hostname -I

Example output:

172.24.57.201

To establish a new Windows firewall rule connecting the two adresses, in an elevated PowerShell console type:

> netsh interface portproxy add v4tov4 listenport=8000 listenaddress=0.0.0.0 connectport=8000 connectaddress={WSL IP}

If you think you've made a mistake, delete a portproxy rule using:

> netsh interface portproxy delete v4tov4 listenport=8000 listenaddress=0.0.0.0

Reading the HTTP stream on the client

Depending on your situation, the limiting factor might be computing power (like with an old Raspberry Pi) or bandwidth (unstable network).
If it's bandwidth, use lame.
If it's computing power, use FLAC or WAVE.
twolame is a good compromise, transparent at 320kbps.

In any case you should set a fixed audio format to avoid trouble decoding the stream.
Here are my settings for httpd in mpd.conf:

audio_output {
	type	                "httpd"
	enabled			"yes"
	name	                "WSL MPD HTTP FLAC stream (port 8000)"
	port	                        "8000"
	format	                "44100:16:2"	# fixed audio format to ease decoding
	max_clients              "0"             # 0=no limit
	tags 			"yes"
	always_on 		"yes" 		# do not close at end of playback
	encoder			"flac"
	compression	 	"4" 		        # mid-range compression offer good CPU/size ratio
}

You should be able to read the stream from any machine on your local network. Here are some working commands depending on the format of the audio stream. These imlply a stable stereo 44100Hz 16-bit stream. play is a sox command.

For MP2/MP3 (twolame/lame) :

$ mpg123 [-a hw:MY_DEVICE_HERE] --smooth --buffer 1024 http://{IP}:{PORT}

$ [AUDIODEV="hw:MY_DEVICE_HERE"] play -r 44100 -b 16 -c 2 -t {mp2|mp3} URL

For FLAC :

$ [AUDIODEV="hw:MY_DEVICE_HERE"] play -r 44100 -b 16 -c 2 -t flac http://{IP}:{PORT}

For WAVE :

$ [AUDIODEV="hw:MY_DEVICE_HERE"] play -r 44100 -b 16 -c 2 -t wav http://{IP}:{PORT}

$ curl http://{IP}:{PORT} | aplay [-D hw:MY_DEVICE_HERE] -f cd -

To check the network activity of streaming on the local network, use:

$ sudo iftop

Problems reading MPD HTTP stream

Occasionally, you might encouter some problems reading the stream: sometimes the decoder and the stream are out of sync, that is the decoder decodes faster than the speed at which the stream gets sent. This causes the player to buffer frequently, causing stuttering in the audio output.
As I understand it, it's a very hard problem to solve. A reboot of the machines may be your best hope. Hopefully it happens rarely in my case, and a Windows reboot always solve the issue. Tweaking the player to fix the issue (e.g. by increasing the buffer) will only offset the problem. Whether you're using sox, (c)vlc, flac, ffplay or mpg123, you shouldn't need to tweak the settings for an optimal experience.
See this detailed commentary for more information: #1063 (comment)

If you keep having this problem, you might want to switch to IceCast or SNAPcast as a streaming solution.
https://mpd.readthedocs.io/en/latest/plugins.html#shout
https://mpd.readthedocs.io/en/latest/plugins.html#snapcast

Scripting this

On the client (here my Raspberry Pi), a program probes the stream every 330ms and start playing when it's on:

ADDR=${1:-192.168.1.07:8000}

[[ $1 ]] || echo -e "$0: usage: $0 [IP]:[PORT]\n$0: no address provided, using default $ADDR"
echo $0: listening to $ADDR...

while true; do
		sleep .33s
		# probe for a correct header
		curl -I -s http://$ADDR
		if [[ $? -eq 0 ]]; then
				echo "$0: $ADDR audio stream is ON"
				AUDIODEV="hw:CARD=DAC" play -r 44100 -b 16 -c 2 -t flac http://$ADDR
				echo "$0: $ADDR audio stream is OFF"
		fi
done

Hope this will help some!

[sylsau]

Well, I got too cocky.
Yes httpd works... but after 30min of listening it accumulates a total of 70 seconds of latency. My guess is the decoder on the receiving end decodes a little too slow, and latency accumulates as the music goes on.
Hopefully I have found a better solution, making use of MPD's great capabilities.

I tried experimenting with snapcast, but had even worse results (constant buffering and choppy audio).

The real solution, that actually works

What you'll need : ffmpeg.

Using a pipe output, you can stream directly from the raw PCM data coming out of MPD. I took on the Streaming Guide from the FFMPEG wiki and after a battery of tests, I had it working great:

audio_output {
        type                  "pipe"
        enabled            "yes"
        name                "ffmpeg pipe through udp (flac[flac]@44100:16:2)"
        format              "44100:16:2"
        command        "ffmpeg -flags low_delay -re -ar 44100 -f s16le -ac 2 -i - -f flac -acodec flac udp://{IP}:{PORT} 2>/tmp/mpd_ffmpeg_pipe.log"
}

The -re option is primordial to make ffmpeg match the real-time frame rate of the sample, and not just output things as soon as it gets them.
When ffmpeg uses pipes, it doesn't know the format of the incoming data, so you have to specify it with the -ar, -ac, -f and -acodec options, otherwise you'll get errors.
-flags low_delay may be or not be of use here, it's unclear -- but it looks hackier.

Now this works extremely well on my setup -- by that I mean I get a 1-second latency using FLAC.

Alternatives

You could also use a better suited format for streaming, MPEG-TS, which in theory allows for error and synchronization corrections. However I have not found a significant latency improvement over the FLAC setup.
The problem with MPEG-TS in ffmpeg is that it cannot embed a lot of codecs. It can do: mp2 (with twolame), mp3 (lame), aac (aac), and PCM audio with a hack (s302m). Even though there aren't a lot of tests out there, the ffmpeg aac encoder seems still of questionnable quality, at least compared to lame, so lame is your best bet, but is not lossless.

audio_output {
        type                  "pipe"
        enabled            "yes"
        name                "ffmpeg pipe through udp (lame[mpegts]@320kbps@44100:16:2)"
        format              "44100:16:2"
        command        "ffmpeg -flags low_delay -re -ar 44100 -f s16le -ac 2 -i - -f mpegts -acodec libmp3lame -b:a 320k udp://{IP}:{PORT} 2>/tmp/mpd_ffmpeg_pipe.log"
}

The only way to stream PCM is through an obscure lossless codec, s302m, used for television application. Given that it only supports 48kHz frame rate, it's better to feed it 48kHz audio. -strict experimental option is needed to enabled s302m in ffmpeg.
NB: for some reason, this codec introduces a major startup latency of about 12 seconds on first time launch, but the stream catches up as soon as MPD is paused/stopped. Even using -probesize, -analyzeduration, -bufsize and -buffer_size I wasn't able to impact the initial latency. But it definitely works.

audio_output {
        type                  "pipe"
        enabled            "yes"
        name                "ffmpeg pipe through udp (s302m[mpegts]@48000:16:2)"
        format              "48000:16:2"
        command        "ffmpeg -flags low_delay -re -ar 48000 -f s16le -ac 2 -i - -strict experimental -f mpegts -acodec s302m udp://{IP}:{PORT} 2>/tmp/mpd_ffmpeg_pipe.log"
}

Scripting this

... Or not, because you don't have to: the nature of UDP means you don't need to have an open connection, so ffplay just keeps on listening on the local port until you shut it down or it gets incorrect data. You have one receiving endpoint that listens to any stream coming from the local network.

Depending on the formats, here are the commands, using ffplay:

ffplay -nodisp -flags low_delay -probesize 64 -analyzeduration 64 -ar 44100 -ac 2 -f flac -acodec flac -i udp://localhost:{PORT}

ffplay -nodisp -flags low_delay -probesize 64 -analyzeduration 64 -ar 44100 -ac 2 -f mpegts -acodec mp3 -i udp://localhost:{PORT}

ffplay -nodisp -flags low_delay -probesize 64 -analyzeduration 64 -ar 48000 -ac 2 -f mpegts -acodec s302m -i udp://localhost:{PORT}

I still got questions

I'm definitely not an expert, so I still havesome lingering questions:

• Why is MPD's httpd under performing here?
• Why is streaming though UDP, which is an inferior protocol for streaming, more reliable? Is it because of ffmpeg? Does ffmpeg send special synchronization information in its UDP packets?

[MaxKellermann]

Nobody should be using httpd unless you are running a public radio station. But not for your personal use.
But REALLY REALLY NOBODY should be using the pipe/fifo plugins. EVER. I mean it.
Snapcast is a good technical solution, but if that gives you trouble, we should optimize that.

[sylsau]

Thanks for clarifying.
Snapcast seems like the proper use case here indeed. I'll report on it when I have time to test it out.
Though I'm curious as to why the pipe plugin shouldn't be used?