The issue:

When streaming across the network using via pulseaudio, the audio is extremely choppy. Editing /etc/pulse/daemon.conf and changing the default-fragments and default-fragment-size-msec values does not improve the situation.

The firewall is not enabled on either system. What other options do I have?

Details of the setup:

I use paprefs to enable network audio:

Sender's setup:


Receiver's setup:


Contents of /etc/pulse/daemon.conf:

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
; remixing-produce-lfe = no
; remixing-consume-lfe = no
; lfe-crossover-freq = 0

; flat-volumes = no

; rescue-streams = yes

; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 200000

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right

; default-fragments = 4
; default-fragment-size-msec = 25

; enable-deferred-volume = yes
deferred-volume-safety-margin-usec = 1
; deferred-volume-extra-delay-usec = 0

default-fragments = 5
default-fragment-size-msec = 25

Audio is still rather choppy on the receiver. When using RTP/Multicast, the setup was less reliable, and I wasn't even able to get it working enough to test it.

  • My jit.si audio problems were all solved with a wi-fi extender. What does your signal strength look like? Have any "noisy" neighbors like I did? Beamforming was not a good option for my old wi-fi clients.
    – ubfan1
    May 15, 2021 at 19:56
  • This is just wild speculation on my part, as I have no knowledge in regards to streaming. But recently I replaced PulseAudio with Pipewire, which solved a different problem for me (PA not detecting the correct output device after a reboot). Anyhow, you could try the same route and see if that helps. ubuntuhandbook.org/index.php/2021/05/…
    – Mrokii
    May 15, 2021 at 20:52
  • I will add more information tomorrow. I used pulseaudio's own tools to set it up.
    – RolandiXor
    May 17, 2021 at 7:32
  • Adding information on how you configured PA, ubuntu & kernel version, etc., would certainly help others help you. May 17, 2021 at 11:01
  • @sancho.sReinstateMonicaCellio tbh, I'm not sure it'll help much in this instance. I've been trying to solve this problem on and off for a while and have been digging through bug reports, forums, etc.
    – RolandiXor
    May 17, 2021 at 17:17

3 Answers 3


PulseAudio Documentation

Below is the documentation from PulseAudio's Network Setup ๐Ÿ”—.

Edit: February 13, 2022

Two new sections were added at the bottom; !AirPort and Rygel.

Network Setup

There are several different ways to connect to another PulseAudio server (direct connection, tunnel, RTP) or some other network audio device (RTP, RAOP, Rygel).

Note all methods described here stream raw PCM audio over the network. This can use pretty much network bandwidth (around 1.4 Mb/s for CD-quality sound). If you get choppy sound, try setting a lower sample rate for the network stream. Furthermore, even while many WiFi connections can sustain such bitrates, often the jitter in packet latency makes transmitting low-latency audio over a wireless link infeasible in practice.

Direct Connection

Just set the environment variable $PULSE_SERVER to the host name of the PulseAudio server. Alternatively you can modify ~/.pulse/client.conf or /etc/pulse/client.conf and set default-server. See Server Strings for an explanation of the format. In this FAQ entry ๐Ÿ”— all locations you can specify the server to use are listed. All the methods that connect to the daemon over the network using the native protocol need module-native-protocol-tcp ๐Ÿ”— loaded. This includes tunnels and Zeroconf setups. With this module loaded, the server listens on port 4713 for incoming client connections.


For authentication you need the same auth cookies on all sides. For that copy ~/.pulse-cookie to all clients that shall be allowed to connect. Alternatively the authorization cookies can be stored in the X11 server. The server must have module-native-protocol-tcp ๐Ÿ”— loaded. To enable all audio from all over the network, set the auth-anonymous=1 argument. A more secure options is to manage access to these servers with an IP ACL. This can look like this in your /etc/pulse/default.pa or ~/.pulse/default.pa startup script for PulseAudio:

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

These two modules are not loaded in the default configuration because they might open PulseAudio for remote attackers.

X Forwarding

If the $PULSE_SERVER variable does not exist or is empty, PulseAudio will then check for X11 properties on the root window. These properties are much like environment variables, but will be available remotely if you SSH to another machine with X11 forwarding. You can see a list of PulseAudio related properties by doing:

xprop -root | grep PULSE

The variables names used are the same as those used in the environment, so PulseAudio will look for a property called PULSE_SERVER. Note that only the X11 properties are forwarded over the SSH tunnel, but the pulseaudio client still connects to the server using its own native protocol.

If connecting back to the pulse daemon running on the computer that has the X display is not desired, you can either set PULSE_SERVER=localhost from the SSH connection (make sure module-native-protocol-tcp is loaded though) or run pax11publish -r before SSHing to the remote computer to remove the properties on the root window.

Using a Tunnel

With a tunnel you can create a new sink that forwards all audio over the network to another server. For the sink at the remote server the tunnel looks like just another stream connecting over the network. The same holds for sources. See the documentation on module-tunnel ๐Ÿ”— for details on the module arguments.

Setting up a tunnel requires a running PulseAudio daemon on the remote server with module-native-protocol-tcp loaded, just like with the direct connection. After the tunnel is set up, client applications connect to the tunnel sink on the local PulseAudio daemon. This has the advantage that you can switch the stream seamlessly between a local hardware sink and the tunnel sink. With a direct connection the client generally has to be restarted in order to switch servers. A direct connection has the advantage that the client has more control over buffering parameters.


In order to avoid having to setup tunnel manually between computers on a network, Zeroconf can be used.

Setup module-zeroconf-publish and module-zeroconf-discover manually or use the check box in paprefs.

You can connect to other sound servers running on the LAN by using Zeroconf/Avahi ๐Ÿ”— technology. Therefore make sure to compile PulseAudio with Avahi support and load the Zeroconf modules on all machines on the LAN. In addition make sure to load the module-native-protocol-tcp and that it allows connections from other hosts, see Authorization above.

#for servers
load-module module-zeroconf-publish
#for clients
load-module module-zeroconf-discover

These modules are not loaded in the default configuration because they might open PulseAudio for remote attackers.


RTP is the Realtime Transfer Protocol. It is a well-known protocol for transferring audio and video data over IP. Two related protocols are SDP and SAP. SDP is the Session Description Protocol and can be used to describe RTP sessions. SAP is the Session Announcement Protocol and can be used to announce RTP sessions that are described with SDP. (Modern SIP based VoIP phones use RTP/SDP for their sessions, too) All three protocols are defined in IETF RFCs (RFC3550, RFC3551, RFC2327, RFC2327). They can be used in both multicast and unicast fashions. PulseAudio exclusively uses multicast RTP/SDP/SAP containing audio data.

For more information about using these technologies with PulseAudio have a look on the modules documentation ๐Ÿ”—.

How can I use PulseAudio to stream music from my main PC to my LAN with multiple PCs with speakers?

On the sender side create an RTP sink:

load-module module-null-sink sink_name=rtp
load-module module-rtp-send source=rtp.monitor
set-default-sink rtp

This will make rtp the default sink, i.e. all applications will write to this virtual RTP device by default. On the client sides just load the receiver module:

load-module module-rtp-recv

Now you can play your favourite music on the sender side and all clients will output it simultaneously. BTW: You can have more than one sender machine set up like this. The audio data will be mixed on the client side.

How can I use PulseAudio to share a single LINE-IN/MIC jack on the entire LAN?

On the sender side simply load the RTP sender module:

load-module module-rtp-send

On the receiver sides, create an RTP source:

load-module module-null-sink sink_name=rtp
load-module module-rtp-recv sink=rtp
set-default-source rtp_monitor

Now the audio data will be available from the default source rtp_monitor.

How can I use PulseAudio as an RTP based N:N multicast conferencing solution for the LAN?

After loading all the necessary audio drivers for recording and playback, just load the RTP receiver and sender modules with default parameters:

load-module module-rtp-send
load-module module-rtp-recv

As long as the PulseAudio daemon runs, the microphone data will be streamed to the network and the data from other hosts is played back locally. Please note that this may cause quite a lot of traffic. Hence consider passing rate=8000 format=ulaw channels=1 to the sender module to save bandwidth while still maintaining good quality for speech transmission.

Can I have more than one multicast RTP group?

Yes! Simply use a new multicast group address. Use the destination/sap_address arguments of the RTP modules to select them. Choose your group addresses from the range 225.0.0.x to make sure the audio data never leaves the LAN.

!AirPort RAOP streaming

With module-raop-sink.


With module-rygel-media-server.


The specification of your problem is somewhat light. I suggest you post:

  1. The contents of your /etc/pulse/default.pa.
  2. How you tried to play over the network (if command line, post the exact command).

In the meantime, I won't try writing a generic description on how to use Pulseaudio for RTP/Multicast. I will wait until you add that info to help identifying your problem.

Possibly helpful actions:

  1. Using logging options, see man page.
  2. Test with two computers close to the router.
  3. Try this sequence, if you did not already do that. Check also other answers in the same question.
  4. paprefs can help configuring pulseaudio. Note that after installing it in Ubuntu 20 (you didn't specify your version), all options in paprefs will show greyed out. You have to setup a soft link to the actual version with sudo ln -s /usr/lib/pulse-13.99.1 /usr/lib/pulse-13.99 (sources: 1, 2).
  5. Check the steps in this guide for PulseAudio over network.

Options for streaming audio

Referring to your question: What other options do I have?

Music Player Daemon (MPD)

"Music Player Daemon (MPD) is a flexible, powerful, server-side application for playing music. Through plugins and libraries it can play a variety of sound files while being controlled by its network protocol."

MPD is a mature server-side application, under active development. There is long list of available clients.


"Icecast is a streaming media (audio/video) server which currently supports Ogg (Vorbis and Theora), Opus, WebM and MP3 streams. It can be used to create an Internet radio station or a privately running jukebox and many things in between. It is very versatile in that new formats can be added relatively easily and supports open standards for communication and interaction."

You can find detailed, tried instructions in How do I setup an Icecast server for broadcasting audio in my network?. No need to copy-paste that here.

Other options

... listed here.


  1. https://unix.stackexchange.com/questions/471222/pulseaudio-rtp-how-to-play-sound-on-sender-too
  2. https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/RTP/
  3. https://gist.github.com/porjo/5cce51d80b349b984d5e8c1c95066c1a

I upgraded both systems to Ubuntu 21.04 (just routinely), and upon doing so, while RTP/Multicast is no better (in fact, it's worse), using the zeroconf option (See screenshot) is working just fine. It's still not perfect, but far better than before.

It's smooth enough to listen to music from one system on the other, clearly, without constant stuttering or distortion.

enter image description here

  • Glad to hear an upgrade fixed the issue. Feb 13, 2022 at 13:04

Your Answer

By clicking โ€œPost Your Answerโ€, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.