Broadcast Electronics introduced its first AudioVAULT automation system in 1989. The company is now part of the Elenos Group.
Bob Demuth is business development manager, studio systems.
RW: What trends in automation stand out for you?
Demuth: Automation suppliers have two kinds of clients: larger enterprise clients and smaller, more mom-and-pop clients. Both want the ability to do more with fewer people, to empower the staff they have to do as much as they can and from anywhere.
Even mom-and-pops might have a station in Keokuk, Iowa, and a station in Moline, Ill. They aren’t iHeart or Beasley but they still have multisite operations, and they’re looking to maximize their efficiency and labor force.
Our development is geared as much as possible to provide remote voicetrack capability, remote production capability, remote scheduling capability, which might be from home or another location.
RW: When you’re sitting down with somebody who’s considering a system and they say “Well, I hear I need to be thinking about the cloud,” how does that conversation go?
Demuth: I’m in development and I also run international sales for BE, so I get both sides of this.
Nobody wants all their eggs in a cloud basket. That’s the overwhelming response that I get.
They’re happy to have the cloud as a backup, as a storage or transfer point for audio, but nobody wants their final playout audio coming from the cloud at this point.
This is a personal opinion, but the next war is not going to be bombs and missiles, it’s going to be an attack on infrastructure. And the major infrastructure that we all use every minute of every day is the internet.
Playout from the cloud is only as good as that connectivity. If that goes away, what do you do?
So most of my customers look at the cloud as more of a backup and a transfer medium rather than a primary playout source.
I’m an old-school radio engineer, I would rather invest my time and money with a playout system at my transmitter site that’s fully linked. If I lose my connectivity, whether it’s IP connectivity or traditional microwave, at least I have something that’s still running on its own.
We’re working now on one of the largest AudioVAULT projects BE has ever done, a major customer that runs a couple of dozen networks. They’re uplinked, streamed and delivered via set-top boxes around the world.
One of their design criteria was that we did not depend on their corporate VPN for the distribution of the audio. This is a large company with a lot of resources and some of the best connectivity, but they are not prepared to make their primary, or even backup, broadcast functions dependent on that connectivity.
I know National Radio Systems Committee working groups are looking for a cloud-based solution for HD Radio, a solution that takes the hardware out of it and puts the software on the cloud for encoding of HD1, HD2 etc., and centralizing it. But it seems to be driven by the larger corporate broadcaster companies more than the average broadcaster.
Currently our cloud offering is about transferring assets via the cloud, with automatic or on-demand uploading, storing and transferring, making those assets available across an organization’ s locations. We will be coming out with a cloud-based playout system for backup use later this year. There is no technical reason this couldn’t be used for on-air if there is enough internet bandwidth available for the desired audio quality. But I do not see many people looking for that as their primary cloud source.
RW: Do you see more joint projects happening, for instance between automation and the AoIP network?
Demuth: Absolutely. We need to be doing more than just pumping out automation over AoIP, meaning playing audio over a WheatNet, Livewire or Dante audio driver. We need more of an integrated functionality with console providers.
Why don’t we see more joint development? Some of us try to cooperate, but if a company like Telos Alliance decides to do joint development with BE, how do they deal with RCS or with WideOrbit? Will Wheatstone continue to cooperate and develop with BE?
Pick one and you alienate the other. That’s the biggest block to all working together is our natural, competitive nature. That, and how do we deal with proprietary information and “trade secrets.”
Yet there is more going on than some engineers might realize. For instance, we offer complete remote control capability with both Axia Livewire and WheatNet, we’re doing more than just sending AoIP out of our playout system and plugging it into an Ethernet switch. We’re also able to send control commands to control surfaces, whether they’re virtual or hardware consoles, whether it’s Axia or Wheatstone or Lawo.
RW: Engineers need to know about a supplier’s tech support.
Demuth: We have a team of experienced customer service people, some who’ve worked there since the beginning of AudioVAULT. As a customer I bought my first AudioVAULT around 1995. We have had some people working since 1990. There’s experience, accessibility, knowledge, also IT skills.
We all depend on the operating system, and if the operating system has issues, or if the local installation has issues, we have to be able to identify those and point the engineer in the right direction and not just kiss it off and say, “Hey, that’s your network switch, you’ve got too much traffic.” We have to be able to help them troubleshoot it without fixing their IT issues for them.
We are fully manned in Quincy, Ill., 8 a.m. to 6 p.m. Central time. Outside of those hours, we have a callback system and try to respond to any emergency call after-hours within 15 minutes. Our average callback is between 15 and 30 minutes.
I used to run engineering for Beasley Broadcast Group from 1990 to 2007. I chose AudioVAULT back in 1990 and I never regretted it.
RW: What other factors should buyers be considering?
Demuth: If I take my sales and development hats off and go back to my engineering hat, the question is reliability and redundancy.
Is your audio stored in multiple places? What happens if you lose one of those places? Can you get seamless continuity of broadcast operations from this system?
There will always be hardware failures; how does the automation system deal with those failures and provide the broadcaster with rock-solid, reliable playout no matter what happens?
Obviously we can’t control power, e can’t control connectivity; that’s the customer’s responsibility. But assuming they can provide continuous power and provide continuous connectivity, how do we keep continuous audio play?
AudioVAULT offers the ability to store audio on separate servers. So if Server A dies, Server B is reading ahead on that same, or the cloud engine is reading ahead on that Server B. And you can reboot Server A and there’s not even a pop or a click, when Server B picks up.
That’s the kind of system you want. If your main playout engine fails, you want not to have to use a silence sensor to switch over to a backup playout engine that’s playing within a half a song of your main one. Ideally you want to go seamlessly to the backup playout system, without any interruption in programming, so that your listener wouldn’t even notice; that’s what AudioVAULT provides.
You want tools to maintain and operate your system from anywhere. To do production, to do scheduling, to do cloud control, automation control and maintenance from anywhere.
This would be the same if I’m a mom-and-pop or if I’m iHeart.
I’m a very small part-owner of two little radio stations in Aspen, Colo., and I chose AudioVAULT back in in 2005. We have a main system in the studio room, a backup system in the studio room and a tertiary system at the transmitter site, which is at a 10,000-foot elevation.
In the winter, the only way to get there was with a Sno-Cat. I wanted a system that could give me that main, give me that backup and give me that tertiary system, and a transmitter in case I lose all connectivity and can’t get up there for 72 hours or whatever. As long as I can send my logs out 72 hours in advance or I could send them out seven days in advance and I’m still on the air. That’s what I want.
RW: One engineer said about automation, “If I can’t install it or fix it, maybe I shouldn’t have it.”
Demuth: That’s just guys who don’t understand their own limitations and the difference between hardware and IT, software-based, solutions. Hardware is easy to self-install, but software requires specific configuration and integration with IT infrastructure. There is too much risk that an engineer will miss something that will compromise the reliability of the system.
You want the automation supplier to install the system and configure it and teach you how to do it properly. You don’t want someone who’s not familiar with the software to be doing this on their own.
You want them to be integrally involved with the installation, whether it’s done remotely or on-site; there’s no substitute for the on-site engineer and production people. But all of this stuff is too complex for someone to take a piece of software, run “install” and expect to use it and get the best results.
RW: Virtualization?
Demuth: Virtualization is really important to larger customers because it allows them to reduce their hardware profile. For the larger systems that I’m putting in — I’m not going to say they’re exclusively virtual, but virtualization is the future of computing.
It raises some challenges, because if you’ve got four virtual servers on one piece of hardware, you only have one video output. How do you deal with some of interface challenges? Your software has to work a little differently. But I believe it is not only the wave of the future, it is the current best practice for larger operations.
RW: Another engineer told me, “I don’t like it when suppliers go back to the well all the time with upsells.”
Demuth: AudioVAULT is all-inclusive software. You buy a license and you get all of our tools.
There are some options that are add-ons, but we are upfront about them. An example is our remote access stuff. It requires a separate gateway server, because if you’re going to open up your automation system to the internet, which is what you have to do to remote voice track and remotely operate, you need an interface sitting on a firewall.
So the internet traffic talks to the gateway server, and then the gateway server talks to the automation system, so the outside world can’t get to your automation system.
Another example are our cloud-based tools. They are extras, because not everybody wants those functions, but that’s not an upsell. We’re straight about that from day one, we don’t hide anything.
But we don’t sell the production screen separate from the import screen, separate from the automation screen, etc. It’s a single, all-inclusive, license for all normal station functions.
RW: And what about low-cost or free software that’s out there?
Demuth: What is your tolerance for being off the air? That’s the answer to these cheap automation systems.
