Jtdylktuy

I want to send sound over the network. I have managed to do this with setting the environment variable PULSE_SERVER=$IP on the client.
On the server side, I ran paprefs and enabled network access to global sound devices.

This pretty much worked out of the box and made sense to me - I'm just forwarding the sound to a remote socket instead of a local socket.

Yet, in various tutorials the general setup seems to be to have a pulseaudio instance running on the client as well:

• https://manurevah.com/blah/en/p/PulseAudio-Sound-over-the-network


• https://www.willprice.org/2013/05/10/pulseaudio-network-streaming.html

Can anyone explain the differences between the two setups? What are the advantages and disadvantages?

As far as I understand it:

• Having a local server lets you use different transports (anything that pulseaudio has a module for – e.g. you can load the RTP or AirPlay modules for compressed audio), while libpulse itself is limited to the uncompressed "native" PulseAudio protocol.




• Having a local server lets you transparently switch between local and remote outputs. You can add a remote sink on the fly, without needing to restart programs with the new $PULSE_SERVER set. I think you can even use module-combine-sink to output the same audio through both devices (if it can cope with the differences in latency, that is).




• For that matter, the local server can even automatically discover remote sinks via Avahi (mDNS) – you enable it and they just show up on the list.




• Having a local server lets you choose which device should run CPU-intensive filters (equalizer, effect modules, etc.) – you can load them locally if streaming to a Raspberry Potato, instead of having the receiver do all the work.




• Having a local server might also improve program performance as some libpulse operations receive local responses instead of having to wait for the remote server. (That said, I'm not sure which operations would be affected in reality. But I think it might make a very noticeable difference when the server goes down.)

It's similar to using Xpra or RDP/VNC versus raw X11 forwarding. Having an intermediate X server on the "remote" side allows it to be smarter about network conditions (e.g. Xpra dynamically enables JPEG compression when it detects lag), provide error recovery and on-demand detach/reattach, and even GPU acceleration; whereas directly pointing $DISPLAY to another host means transferring huge raw pixmaps and crashing & burning every time the connection is interrupted.