The Musical Raspberry Pi has been working a treat! I was planning on upgrading to a more HiFi case, but to be honest I like the look of the exposed PCB in the clear case the Pi came with!
This is a quick post following up on a few things learnt since getting my musical Raspberry Pi up and running. What was working:
- PulseAudio
- Airtunes support via ShairPort
- UPnP support via gmediarender-ressurect
- Audio redirection from Linux via PulseAudio
What wasn’t working:
- Audio redirection from Windows
- Proper init scripts for ShairPort and gmediarender-ressurect
Since then I’ve found Airfoil for audio redirection under Windows.
Day to day
It’s been nice and smooth running since getting up and running – the WAF has been high so far! We’ve been using the speakers almost daily, partly novelty I’m sure, but partly because they’re there and it’s easy and hassle free to use them.
- MPDroid
- Works well most of the time, but a little clunky at times. I think this may be a good reason for me to get my hands dirty with some Android coding.
- MPoD
- Works very nicely and just feels a lot more polished in comparison (as ever :().
init script problems
I wasn’t happy with the rc.local approach for starting up ShairPort and gmediarender-ressurect. There were a few different avenues I had to explore before I managed to get things sorted out.
Soundcard order
A lot of the other posts on the web talk about changing the alsa module index so that the usb audio is used as the preferred device.
Done by changing /etc/modprode.d/alsa.conf to look like:
#options snd-usb-audio index=-2
options snd_bcm2835 index=-2
For me this didn’t change anything, the rc.local approach was still the only one that worked.
Permissions
In an attempt to track down the problem it turned out trying either aplay or paplay as root both failed with various permission denied problems.
The quick fix here is to add the root user to the pulse-access group:
root@raspberrypi:~# groups root
root : root indiecity
root@raspberrypi:~# usermod -G root,indiecity,pulse-access
With this problem resolved the init script problems all went away.
This also explains why other people weren’t having issues with the ShairPort init script, it was the use of PulseAudio that was root (ahem!) cause.
Working init scripts
The supplied init script for ShairPort now works. To install it:
pi@raspberrypi ~ $ sudo cp src/shairport/shairport.init.sample /etc/init.d/shairport
pi@raspberrypi ~ $ sudo insserv shairport
I tweaked the DAEMON_ARGS line to set the instance name as to use PulseAudio:
DAEMON_ARGS="-w $PIDFILE -a air-pi --ao_driver=pulse"
I’ve also knocked together an init script for gmediarender-ressurect based on the ShairPort one that works well:
#!/bin/bash
#
# This starts and stops gmediarender-ressurect
#
### BEGIN INIT INFO
# Provides: gmediarender
# Required-Start: $network
# Required-Stop:
# Short-Description: gmediarender - UPNP renderer
# Description: UPNP renderer!
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO
# Source function library.
. /lib/lsb/init-functions
NAME=gmediarender
DAEMON="/usr/local/bin/gmediarender"
PIDFILE=/var/run/$NAME.pid
DAEMON_ARGS="-P $PIDFILE -d -f upnp-pi --gstout-audiosink=pulsesink"
USER="pi"
[ -x $binary ] || exit 0
RETVAL=0
start() {
echo -n "Starting gmediarender: "
start-stop-daemon --start --quiet --pidfile "$PIDFILE" \
--exec "$DAEMON" --oknodo -- $DAEMON_ARGS
log_end_msg $?
}
stop() {
echo -n "Shutting down gmediarender: "
start-stop-daemon --stop --quiet --pidfile "$PIDFILE" \
--retry 1 --oknodo
log_end_msg $?
}
restart() {
stop
sleep 1
start
}
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status gmediarender
;;
restart)
restart
;;
*)
echo "Usage: $0 {start|stop|status|restart}"
;;
esac
exit 0
Installing it is done in exactly the same way as for the ShairPort one. If you are not using PulseAudio take out --gstout-audiosink=pulsesink option on the DAEMON_ARGS line.
Hi Mark,
Really interested in your Musical Pi work. I’m a bit confused as to how I get this going on my Pi though. Is there a prebuilt card img for this, or do I need to do is the edits to an exist vanilla os install of some kind? I’ve looked in the GitHub link, but can’t work out what to do!
Sorry if I’m being a bit thick. 🙂
Cheers
Dave
Hi – my setup is done by making changes to the basic Raspbian install.
There is a fair amount of detail missing if you’re not familiar with Linux.
Raspify was an installable image, which now appears to have been renamed to something called Volumio. I’ve not had any experiences of it, so your milage may vary.
Good luck! Shout if I can be of any more help.
Hi Mark,
I run a rpi-updated Raspbian with a HiFiMeDIY usb DAC and a WN725N wifi dongle (8188eu). Using xmms2 configured to output directly through alsa, I can hear clicks-n-pops more often than not, when playing either FLAC from a usb stick or a 128k mp3 http stream. I have upped the xmms2 output threads nice and ionice values to -10 and RT, but still get the quirks.
Any idea what might cause the glitches, or if using pulse-audio would help in any way ?
Amusingly on this system, playing the mp3 stream continuously for a few hours causes the sound to eventually lags 5 to 10s behind compared to a reference xmms playing the same stream on an eeepc. Do you experience the same lag on your system ?
I certainly had a lot of nasty clicks in the output when running PulseAudio as a standard user. Switching to running it as a system wide root installation helped. The main reason I went for PulseAudio was to allow more than one application access to the sound output at a time. If I was just running MPD on the Pi I would probably have just used the standard Alsa output.
Is it only xmms that is causing problems?
Personally I’ve never used xmms – do you need to have X running to use it? I run the Pi without X, so that is a possible difference between our setups.
Using mplayer via alsa (mplayer -ao alsa file.flac) plays back absolutely fine even streaming a file over wireless via NFS.
I’ve never tried running a stream through two systems at the same time. I don’t believe the Pi has a particularly accurate clock so it could be something like the two clocks of the relevant machine drifting relative to each other. I’m not sure if that could cause the problem you are seeing? Alternatively I guess the clocks/pops in the playback could be causing slips in the timing, which will add up over time.
Thanks for your answer and suggestions.
1. mplayer, play (sox), avconv (ffmpeg)+aplay all show the same issue on my setup when going directly through alsa to the usb dac
2. never tried the onboard audio as a.) goal was using a (better) usb dac, and b.) I take for granted that onboard audio will work without glitches.
3. xmms2 is headless
You are right to suggest isolating the issue. I have long suspected the pb lies with the shared usb bus and/or wifi dongle. Using an old wg111 or using wired network worked better iirc, but I need to re-test. That probably wont fix the issue with usb sticks though.
I’ve done some tests and can’t cause playback with alsa to have problems I’m afraid.
The Raspify project guys had a pretty extensive list of performance tweaks they made to get stable audio playback. May be worth trying some of them. Personally I’ve not done any of them, so YMMV.
Which HiFiMeDIY DAC have you got? Mine reports a USB id of 1852:7022.
In terms of a wireless adaptor I’m using one based on the Realtek RTL8188CUS chipset. It’s one of the really small nano wireless dongles. The range isn’t good, but the power usage is low.
Thanks for following up !
I use the mid-cheap one, 96khz/24bit, SA9023 usb adapter (model 10000033 on their site); lsusb reports 262a:10e0. My wifi dongle is a WN725N v2, chipset is 8188eu. All in all, we have a pretty different system.
AP and dongle are about 8m apart; my wifi env is admittedly crappy, be it the AP (on which I have no control), conflict or radio noise from neighbours, local wifi devices, or the wn725n v2 dongle range, or driver. Too many moving parts.
Using wired network, or placing the wifi dongle in a better position (checked link quality with iwconfig), anything that betters network perf did result in no audible clicks for the duration of my tests. I double-checked kern.log for alsa messages and found none. Conclusion so far: pb is related to the WN725N v2 dongle and/or driver; or crappy wifi env causing it to misbehave. I have ordered an edimax EW-7811UN nano to compare.
On the RPi I tried some tweaks, e.g. unbinding the hciusb driver or overclocking to 900MHz; did not help much, or improvement was hard to measure, as clicks remained occasional. I reverted to “default” raspbian config, no alsa tweaks, no overclocking, just rpi-updated kernel and firmware, and xmms2 writer threads prio and ionice upped.
I did not re-test extensively with playing FLACs from a usb stick. Final note: my rpi runs off an unrated usb charger (APC), rpi usb port connected to a 4 port passive usb hub (trust barra mini), with 3 connected ports: dac, wifi, and usb key.