Friday 23 July 2021

Broadcast Audio Throughout your Home (RTP)

Introduction

Are you interested in playing audio throughout your home but do not want to rewire it with expensive audio cabling? you might want to try RTP over your existing wired LAN.  I tested this with my own wired LAN involving Linux PCs and a Smart TV.

Prerequisites

This was tested using the following equipment and software, RTP is just a protocol though and I see no reason why you could not achieve the same results using other hardware and/or software:
  • Sony Bravia Smart TV
  • Linux Pulse Audio
  • VLC
  • NTP (Network Time Protocol)

Timing is Hard

One of the most difficult problems to track down in my experience getting this working properly was how sound would fall out of sync every now and then.  I wrongly assumed this was due to network latency.  The real cause of the issue was system clocks being out of sync on the playback devices.  If you're using computer systems then this is relatively easy to resolve, just make sure you have NTP enabled (Network Time Protocol) on all devices and make sure it regularly keeps the system time in sync.  
 
On a TV this is much harder.  My Sony Bravia uses network time but it still falls out of sync most likely because clocks vary in accuracy (my brand new over-the-range Microwave fell several minutes out of sync with everything else in my home only months after correcting it).  To work around the issue on my Sony Bravia I went to the date/time settings and disabled automatic time and then re-enabled it again.  This forced the system to use NTP to update the system clock immediately.  In my case it was out of sync by about 5 seconds, not a lot right? well, it is more than enough to make RTP unusable.  Finally, I made sure I restarted VLC (more on that later).

Setup the RTP Sender

Firstly, I configured a virtual output device on the Linux PC where I wanted to broadcast audio from.  Place the configuration below into your /etc/pulse/default.pa configuration file.  This is so that the changes persist after reboot.

.nofail
load-module module-null-sink sink_name=broadcast sink_properties=device.description=Broadcast
load-module module-rtp-send source=broadcast.monitor loop=true source_ip=192.168.1.2 port=2000 ttl=1
load-module module-rtp-recv sink=speakers latency_msec=1800
.fail

The key elements here:

  • Broadcast - virtual audio sink, use this like a speaker for broadcast audio, on its own it's just a dummy sink that doesn't do anything, but the associated monitor source we care about for the RTP broadcast.
  • broadcast.monitor - the associated source of the same sink, read from by the RTP send module to do the actual broadcasting
  • loop - playback the audio on the local machine too, otherwise it just broadcasts the audio to the network and ignores your speakers
  • speakers - a virtual sink I created that maps to my speakers
  • latency_msec - compensation for network lag, makes audio synchronized, set to a higher value to compensate for more network latency on your LAN.
  • .fail / .nofail - atomic transaction, if any of the commands between these two tags fails, then undo everything that was ran successfully inside these two tags.
  • ttl - Time-to-Live, this is a security measure, it makes sure that packets broadcast over your network will not reach beyond your immediate local area network.
  • port - The UDP port to broadcast packets over, this is important and must be fixed.

This gets the RTP setup going on one machine for both sending audio to the Local Area Network as well as playing it back on the same machine's speakers.

I set a latency milliseconds value of just under two seconds, which makes audio playback on the local machine delayed by about two seconds because it takes about that long for the audio to playback in the other room over the network.  Set this to a higher value if you have very bad network latency.

The other point worth mention is the UDP port value, I set this to 2000, which is the Cisco SCCP protocol, which I don't care about on my LAN.  I first set it to 556 and this didn't work, probably because this is a privileged port, which are typically prohibited by many devices.  If you don't set a fixed port then the RTP transmitter randomly picks a port each time and some RTP receivers don't like that.

RTP Receivers

Now it's time to setup the receiving end of playback

Linux Receiver

It is very easy to do this, you can use the paprefs utility but I prefer to look at the raw configs.  Just like with sending, place the following configuration into your /etc/pulse/default.pa configuration file on the receiving host:
 
load-module module-rtp-recv

You can specify a sink if you want but otherwise this will playback audio on the default speakers configured for the system.

Sony Bravia Smart TV

Playing back RTP on a Smart TV was also pretty easy, just install VLC for Android from the Google Play Store.

Once setup add a network stream:

  1. Go to BrowsingStreams 
  2. Now enter the following URL:
    rtp://224.0.0.56:2000/

The URL here indicates a few things:

  • RTP - The Realtime Transport Protocol
  • 224.0.0.56 - This is the built-in UDP broadcast IP address, if a switch receives packets from this IP address it broadcasts them to everything on the network, if a host receives a packet from this IP address it has the option of reading it.
  • 2000 - This is the UDP port we configured our RTP sender to transmit packets on

That's it! now you're ready to start playback.  Use your TV remote to activate the link.  If you hold your remote activation button VLC will let you rename it, I named mine LAN (wow, creative).

Broadcast Audio Throughout your Home (RTP)

Introduction Are you interested in playing audio throughout your home but do not want to rewire it with expensive audio cabling? you might w...