Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It only takes a minute to sign up.
Sign up to join this community
I'm trying to set up a PulseAudio sink on my Raspberry Pi, in order to stream all system sounds from my PC there. What is the best way to do so?
For example, is it possible to watch movies or is the latency too high? I tried this a while ago using gstreamer, but with a latency of about 2 seconds, which is useless for my requirements.
The official instructions for creating a "direct connection" on a network hopefully just work for most people, but it seems pulseaudio and I do not get along that well: it took me hours. [Besides "direct connection", you can also use a "tunnel" method described further down, but I recommend reading this first.]
I now have a (fedora 17) desktop streaming sound to the pi. I've minimized the /etc/pulse config files on both sides. On the desktop side:
/etc/pulse/client.conf
# See man pulse-client.conf
default-server = tcp:192.168.2.13:4713
My pi's LAN address with the default pulseaudio port. But here's something that then had me confused for a while — with a server specified, pulseaudio would not even start:
> pulseaudio --start
N: [pulseaudio] main.c: User-configured server at tcp:192.168.2.13:4713, refusing to start/autospawn.
It will run in the foreground (probably because it then doesn't read pulse-client.conf?). However, as it turns out, you don't have to run it at all on the desktop (sending) side, something which is not spelled out in the pulseaudio docs. Using lsof -i -P it appears that lower level plugins for various media players do the work.
So, that one line "client.conf" is actually all you need on the desktop/client side, if all you are going to do is use the network (but see "Yet More Complications", below).
Although the pulseaudio daemon (on the receiving/server side) can be run as a system service, the developers of pulse recommend against it, and in fact on the pi the init script just causes a warning to be issued: you still have to start it yourself. Fedora does not even include a systemd boot service entry for it.
Hence, on the pi side, you should explicitly start and stop the pulseaudio server process, configured thusly:
/etc/pulse/daemon.conf
# See man pulse-daemon.conf
log-level = info
exit-idle-time = 10800 # 3 hours
You can use -1 for exit-idle-time to keep the daemon running indefinitely. Beware this is seconds and the default is 20 (meaning it will keep "mysteriously" dying if you don't set this).
/etc/pulse/default.pa
# See man default.pa
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.2.0/24
load-module module-alsa-sink device=hw:0,0
Since this is a network app, it's not a good idea to run it as root. However, as mentioned in man pulseaudio, it is also a good idea to "renice" the process to give it a higher priority. You can do this manually with nice, but pulseaudio will do it automatically for root, or members of the pulse-rt group, if the executable is "setuid", meaning it can make use of some root privilleges and then change down to the correct unprivelleged uid (ping and passwd also need to do this). So (as root, or sudo):
chmod u+s /usr/bin/pulseaudio
There is no pulse-rt group created when pulseaudio is installed on raspbian, so then:
groupadd pulse-rt
This will give you a gid like 1003. Add (e.g.) user pi to that group:
usermod -aG pulse-rt pi
But on raspbian, you still won't be able to renice as pi. For that, add to /etc/security/limits.conf:
@pulse-rt hard nice -20
@pulse-rt soft nice -20
You have to actually run a log in before these changes take place; if you use ssh with the pi, just use login. Now you can start pulseaudio and it will renice itself -11, which is probably a higher priority than most of the other processes (look at the NICE value in top).
While playing sound streamed from the network, pulseaudio on the pi uses about 10% of the CPU and a trivial amount of memory. :) It and my desktop are on a wired LAN; pulse streams raw pcm data (I believe), so bandwidth usage corresponds to the sample rate of the source, 1 kB/s and up. There is, unfortunately, a noticeable lag in the sound if you are watching video.
Unfortunately, none of the various sound applications from my PC worked right away; mpg123 would not run at all. For that, on fedora, you need the mpg123-plugins-pulseaudio package. For flash stuff in the browser (eg, youtude) you need alsa-plugins-pulseaudio (these are what actually connect to the remote server). Other distros should have similiar packages. If you've been using pulseaudio before (I was not), you may have them installed already.
KDE's desktop bells and whistles also did not work. This is a harder issue to resolve, because it looks for a local pulseaudio server, and as described, using a direct connection means no server can be run locally. The way around this is to use the "tunnel" method.
This is the other way mentioned in the pulseaudio docs. In this case, you have a server running on both sides and one hands off to the other. To do this, comment out the "default-server" in /etc/client.conf and add a local /etc/default.pa containing:
load-module module-tunnel-sink sink_name=rpi_tunnel server=tcp:192.168.2.13:4713 sink=bcm1
If you don't put a sink_name in, pulseaudio won't start. The sink refers to the sink name on the pi side, which then also needs a name; add a corresponding sink_name to the module-alsa-sink line in default.pa there:
load-module module-alsa-sink device=hw:0,0 sink_name=bcm1
Start the server on both sides and presto...sort of. While everything including KDE bleeps were now carried, browser flash playback stuttered badly. However, under another desktop environment (actually, just a window manager, fvwm) it was fine.
I like KDE but can live without the bleeps, so for now I'm going to stick with a direct connection.
If you have problems, using pulseaudio -vvvv --log-level=debug on the pi provides a lot of debugging messages. Initially when I could not get sound on the pi this reported a problem "related to a bug in the ALSA bcm2835 driver" which seemed odd to me since the sound was fine with just alsa, and I'm sure there's pi software around that depends on pulseaudio — apt-get remove pulseaudio and a re-install apt-get install pulseaudio seemed to fix this... Not a solution I like to see, but hey, at least now I can listen to tish without having to plug speakers into every box. Mostly.