As director of Omnia radio processing sales for Telos Alliance, I get to talk to some very IT-savvy engineers who have either moved their audio processing into virtual environments or are flowcharting future deployment.
From these conversations, I created a checklist of some things you should consider before virtualizing your audio processing.
Before we dive into the list, however, we should answer the most often-asked questions: “What is this virtualization business? And why is it useful?”
Virtualization
Virtualization is the concept of taking a server and, with the help of virtualization software, partitioning it so that it appears as several virtual servers running their own operating system, allowing the user to employ the server for several different applications instead of just one.
[Related: “How to Pick an On-Air Processor”]
As applied to audio processing, imagine running hundreds of FM, HD or stream-processing instances, delivering content where needed and backed up on-premise or off-premise (cloud).
Why virtualize?
There are a number of good arguments for virtualization. Among them:
- Less dedicated broadcast hardware. Saves on IT costs and electricity, too.
- Backup, disaster recovery, redundancy and uptime. Think multiple servers to load balance or for failover, keeping your infrastructure more available and allowing for multiple backups or cloud deployment.
- Local studio rule changes. Send FM composite direct to transmitter sites over redundant paths using Omnia’s µMPX codec (MoIP or Multiplex over IP).
- Combine all efforts for FM-RDS, HD and streaming! Run multiple instances on one server. Smaller footprint, easier to manage, provides consistency.
- Spin up or turn off instances as needed, operate on-premise or in the cloud. Need a holiday stream?
- Sign-on a new station or format? Changes like these can be handled quickly.
- Future-friendly. With software, we can add new features as standards or operating systems change.
Just over a year ago, Omnia released its first virtual audio processing ecosystem, Omnia Enterprise 9s, which is designed for high-density or virtual deployment. It’s based on the sound, performance, features and interface of our famous Omnia.9 hardware audio processing platform.
Pictured in Fig. 1 is the interface of the Omnia Enterprise 9s, which, if you are familiar with an Omnia.9, is identical.
However, look closely and you will see one major difference: options for Stations 1 through Station 8. That’s separate processing paths for eight radio stations, all running on one server.
Checklist to Deploy Processing Virtually
1- Bandwidth — Not everyone has access to fiber. With the Omnia µMPX codec in the Enterprise 9s, you don’t need that kind of bandwidth to send the entire FM baseband with RDS and stereo pilot across a link. With µMPX, it passes at a low bandwidth of 400 kbps without degradation of the audio baseband or transcoding artifacts. FLAC can be sent at 800 kbps.
2- Secondary ISP — Seriously consider a secondary ISP to carry your content or composite signal in the event of main failure. You’ll find two NICs on the rear of the Omnia MPX Node for full redundancy capability. For that matter, Starlink (from Elon Musk) may soon become an option for transmitter sites way past “the end of the internet.”
3- Appropriate Server, CPU or Host — Assuming you are running a virtualized environment for your audio processing. In our cloud testing of Omnia Enterprise 9s, moving from one physical server to another requires little or no “hit” or downtime. For users deploying one instance of Enterprise 9: each FM and µMPX output requires four CPU cores and 500MB total RAM.
4- Handling I/O — In the Omnia Enterprise 9S environment, here’s what is available today:
Input — Livewire, AES67 and Windows drivers. Stream receiver.
Output — For true MPX out, including pilot and RDS, you will need to license the µMPX codec for FM transmission over some type of IP link with Omnia MPX Node hardware deployed at the transmitter site (Fig. 2). In that figure you also see an Omnia.9sg deployed (optional). The Omnia Enterprise 9s software can encode a lossless FLAC stream, which the 9sg can use to make composite at the transmitter site.
5- Handling EAS and PPM — EAS: If your studio or program feed is generated elsewhere, current solutions include having your EAS unit at the transmitter, on its own separate local audio processor.
Watermarking: Stations in PPM metered markets that want to virtualize their airchain will need a way to properly watermark their signal. Full market testing has rolled out in a couple of large markets for MRC accreditation with Nielsen. While not released yet, this initiative will put the watermark where it belongs, inside the audio processor. (Our Linear Acoustic TV processors have had Nielsen watermarking for some time.) This also eliminates maintaining a hardware watermark encoder.
6- Appropriate IT Department — Do I have the appropriate IT talent to maintain the IP paths to where audio, or composite, is delivered?
7- Can I get this in a container? — This is on our roadmap.
To help illustrate redundant paths to the transmitter site, Fig. 2 shows two ways to generate composite with Omnia Enterprise 9s on a server, feeding:
- µMPX Codec over IP to Omnia MPX Node: Omnia MPX Node encoder and decoders come with support for NET1 and NET2 ethernet jacks, for full redundancy using two IP paths.
- Omnia Enterprise 9s to Stereo Generator: The other path shown would send FM out from the Omnia Enterprise 9s as audio to an Omnia.9sg. FLAG encoding/decoding is another option to form your own STL.
It’s fascinating to see stations using this Omnia Enterprise 9s product in so many different ways and workflows. It’s a credit to the ingenious radio engineers in the industry that no two deployments have, so far, remotely been alike.
Questions about this article? Email Paul Kriegler at [email protected] or Mary Ann Seidler at [email protected].
