I saw a forum post about someone who was using PulseAudio remote (client-server setup) and this interested me. PulseAudio has some very advanced features that I hope to use to be able to play music throughout my house without buying a commercial system such as Sonos to do that.

So far I was able to get PulseAudio remote working, but not exactly according to the directions given. In particular, I think I have opened up some security holes. I would like to give the exact steps I performed and see if anyone can tell me where I went wrong.

To be clear, PulseAudio is working and I do not get errors. But I had to open up more settings than I should have. My goal is to go from this poor working configuration to a proper and secure working configuration.

My PulseAudio client and server both run Arch Linux.

client and server both

Install this package and enable avahi-daemon:

pacman -S pulseaudio-zeroconf 
systemctl enable avahi-daemon.service
systemctl start avahi-daemon.service

server steps

Edit /etc/pulse/default.pa and add these lines:

load-module module-native-protocol-tcp auth-ip-acl=; auth-anonymous=1
load-module module-zeroconf-publish

Run these commands:

pulseaudio -k
pulseaudio --start
pacmd list-modules | grep native-protocol-tcp
pacmd list-modules | grep zeroconf-publish

The modules were correct.

client steps

Edit /etc/pulse/default.pa and add these lines:

load-module module-native-protocol-tcp
load-module module-zeroconf-discover

Run these commands:

pulseaudio -k
pulseaudio --start
pacmd list-modules | grep native-protocol-tcp
pacmd list-modules | grep zeroconf-discover

PulseAudio started and the modules were correct.

My next step should have been, "Run the graphical PulseAudio Volume Control pavucontrol. Under the Output Devices tab, you should see the local and remote output devices." However, when doing that, I did not see any remote output devices on the client.

I had to open paprefs in a terminal and do the following extra steps:

Network Access tab on client:

  • check Make discoverable PulseAudio network sound devices available locally

Network Server tab on server:

  • check Enable network access to local sound devices
  • check Allow other machines on the LAN to discover local sound devices
  • check Don't require authentication

Only after those changes in the GUI of paprefs did I see remote output devices on the client. As mentioned, playing music to a remote sink is working, but these settings seem insecure and I suspect I missed something important in my configuration. As soon as I uncheck "Don't require authentication", streaming stops.

Also, is there a better way to do this than using avahi?


1 Answer 1


On the server, I changed the following config line from:

load-module module-native-protocol-tcp auth-ip-acl=; auth-anonymous=1


load-module module-native-protocol-tcp auth-ip-acl=;

I copied the same ~/.config/pulse/cookie file to all devices.

Next, on the server open paprefs in a terminal and do the following step:

Activate Network Server tab:

  • uncheck "Don't require authentication"


I also found another way to accomplish basically the same thing, which is controlling music playback from my laptop while the music is played on/through a different computer which acts as a music "server" and is connected to the speakers (and DAC, power amplifier or whatever music setup one has). I have convenient ssh access set up between the devices on my LAN. I installed the application cmus on my music server.

cmus is a small, fast and powerful console music player for Unix-like operating systems.

Now I can use my laptop (or phone) as a "remote control" for my music server by ssh'ing into the music server and typing cmus into a terminal. I have tried other methods of remote controlling music being played on a different computer, and I have to say there is an enticing elegance in the console interface of cmus.

For cmus instructions, type man cmus-tutorial and man cmus.

  • sorry, just a basic question for you: is pulseaudio streaming working well for you? especially in terms of lags, buffering and sound quality.. I have been using it years ago and it was awaful (lags) so I wonder how things changed over the time.
    – greengold
    Commented Sep 22, 2019 at 12:40
  • Yes, it is working well enough for me now. On my LAN I had to set latency_msec=2000, and I use unicasting (to multiple receivers) instead of multicasting.
    – MountainX
    Commented Sep 24, 2019 at 3:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .