Run scalable radio processing using Ross RSAP on AWS

This blog is co-authored by Rafal Kulczycki, Software Developer at Ross Video and Dilip Sant, AWS.

Radio broadcasters continuously seek options to improve operations, build resilient networks, and operate in a high-performance, redundant infrastructure. This all comes at high cost, for both hardware and ongoing maintenance. When a customer of mine recently asked how Amazon Web Services (AWS) could facilitate improvement, I started looking at ways to run radio workloads on AWS. Ross Video recently announced its Ross Production Cloud built on AWS, and its product, Radio and Streaming Audio Processor (RSAP), is used by many radio broadcasters to create a sonic signature for their stations. The audio brand is critical for every radio station, and RSAP provides a virtualized implementation of Orban Audio Processors. I reached out to the Ross team to explore how one might run this workload today on AWS.

Before we discuss the architecture, let us understand how RSAP on AWS might facilitate solutions. Using solutions built on AWS, you can iterate quickly and experiment with new ideas. Managing changes, upgrades, and replacements becomes more straightforward than running operations on-premises. You can use the AWS global infrastructure to span across geographies and operate the same technology stack more easily and remotely.

There are many reasons customers look to AWS for their workloads. Using AWS, some of our customers have said that they can:

• Accelerate production and operation with ready-made solutions and partners
• Build and operate a second environment for migration, backup, or disaster recovery—using AWS you can scale to meet changing requirements
• Migrate from a traditional network to audio-over-IP (AoIP)
• Experiment on AWS without having to source all the hardware upfront
• Archive data and integrate with Amazon Simple Storage Service (Amazon S3), object storage built to retrieve any amount of data from anywhere, for longer-term retention.

RSAP overview

RSAP is a centralized, multichannel audio processor for radio broadcast and streaming services. It provides world-class Optimod audio conditioning from Orban to create the finest expression of your sonic signature in radio and internet broadcast audio streams. Offering native AES67 with Livewire+ connectivity, RSAP features fully redundant networking to integrate into your audio-over-IP radio broadcast plant seamlessly and reliably.

RSAP is one of the applications that Ross offers, developed on Ross’s softGear platform. It is a microservice-based approach to orchestrating audio and video media processing workflows. In essence, media gets into the system through an I/O block—in the case of RSAP, it is an AES67 receiver—and is then placed on a data plane (produce). The subsequent processing block reads (consumes) that data off the data plane and transforms it in a certain way—in the case of RSAP, it applies advanced loudness processing. If required, the workflow can contain additional media processing components. Finally, the output stream is sent to the network through the sender container. The benefit of the containerized approach is that it allows for better scalability and redundancy over traditional, monolithic applications. In addition, quick modifications and tweaks to an existing workflow are possible.

Customers who use Ross’s softGear would have a flow similar to the following diagram. Because we need a more reliable way to send audio streams into AWS, we convert streams into SRT using hardware on the ground (studio) and sending it to an Amazon Virtual Private Cloud (VPC), which gives you full control over your virtual networking environment.

The following diagram depicts that we have multiple SRT streams coming into the AWS network from multiple studios. Some content could originate in the cloud, particularly content already stored on Amazon S3.

SRT stream flow when running Ross RSAP on AWS

RSAP architecture on AWS

Let’s take a moment to address a few assumptions and trade-offs we make when building this environment. There is no support for Precision Time Protocol (PTP) today within Amazon VPC. Instead, we used chrony with Amazon Time Sync Service as our time source, providing us with a similar, high-accuracy clock originating from the same GPS satellite network.

We built our VPC with AWS Transit Gateway, which connects VPCs and on-premises networks through a central hub for multicast with Internet Group Management Protocol (IGMP) support, and we used AWS Direct Connect, which creates a dedicated network connection to AWS to send SRT streams over a secured private network into our VPC.

AWS VPC Setup with Direct Connect Access to On Premise

In our setup, we used the srt-live-transmit app to encapsulate and send the stream over AWS Direct Connect to our VPC.

In our test studio, we had:

• An AES67-player publishing an audio stream from a file to multicast group called audio_stream_1.
• A server running srt-live-stream and acting as sender, subscribed to the audio_stream_1 It wrapped the audio stream in SRT and transmitted it to a listening party running on AWS through AWS Direct Connect.

On the AWS side, we had:

• An Amazon Elastic Compute Cloud (Amazon EC2) instance, running srt-live-stream and acting as a It unwrapped the SRT and published the received audio as audio_stream_2 to a multicast group on the local subnet.
• RSAP Ross Audio Processor with three components, each running as a Docker image inside an Amazon EC2 instance within the auto scaling group.
  • AES67-receiver receives the stream, time-stamps it with the local time synchronized to Amazon Time Sync Service, and writes it to shared memory (SHM) of the EC2 host machine.
  • Audio processor reads, modifies, and writes the audio stream to another SHM location in ec2-rsap.
  • AES67-sender publishes processed audio stream on a local subnet.
• AES67 consumer (such as VLC player running on Amazon EC2 Windows instance), which subscribes to and plays out the processed stream.

AWS VPC setup with Direct Connect access to on-premises

Conclusion

We demonstrated that transmitting AES67 streams from an on-premises studio to AWS for processing is possible. AWS is a feasible option for distribution using fast network infrastructure and storage. 

An area that requires more work is a study in the synchronization of the on-premises PTP clock with the chrony clock in Amazon EC2 instances. Time-stamping or restamping will allow for the AES67 stream to originate from the AWS instance, as well as allow for A/V synchronization with AWS. For this study, retaining the original time stamps helped with synchronization in the downstream devices.

For more details about running Broadcast workloads on AWS, please visit the AWS Media & Entertainment page. For more information about RSAP, visit the Ross Product page.