MARLOW, U.K.—TSL has announced that it is working to help broadcasters migrate to IP infrastructures by launching the MPA1-MIX-NET. Building on the success of its MPA1-MIX family of monitor devices, the MIX-NET extends functionality to ST 2110 AoIP networks.

The intuitive 1U monitor unit provides 64 channels through a 1G AoIP connection, and a further 64 x MADI channels with an optional MADI SFP to provide user access to a maximum of 128 inputs, TSL reported. 

The unit also has native support for NMOS IS-04 and IS-05. Featuring eight dedicated rotary controls to create a monitor mix of up to eight mono or stereo sources, operators can bank up to 16 independent mixes which can be recalled with a user-friendly 'scroll to select' function.

Like previous MPA1 units, development of the MPA1-MIX-NET was driven by changing market requirements, TSL explained. Designed in collaboration with global production giants NEP, the units are lined up for installation in its upcoming roster of ST 2110-compliant trucks and studio installations.

“Operator feedback for our MPA1-MIX MADI and Dante units has always been super positive,” says Joe Signorino, vice president of systems design and integration for NEP’s U.S. Broadcast Services Team. “The control layout is user-friendly with plenty of room to access individual controls, it can be operated without having to look directly at it and basic operations do not require button pushes or menu navigation. We just wanted the same functionality in an ST 2110 environment.”

“TSL has always listened to the market and is always responsive to it; they understood what we were striving to achieve straight away, and the development of the MPA1-MIX-NET has enabled us to provide our clients with the same flexible and reliable monitoring they already know and love,” he added. 

Designed for a variety of operational positions, MPA1-MIX models make it easy to create a variety of custom mixes. With no complex menu structures to navigate and key information such as gain, metering and source labels clearly displayed on its integrated colour screen, thousands of broadcast professionals use them every single day, TSL said. 

The introduction of the MPA1-MIX-NET extends TSL’s MPA1 range to six user-friendly MIX units and six SOLO variants for very simple audio monitoring. All are 1U high and have a compact unit depth of 100mm, while a fanless design makes them suitable for installation in all locations.

In addition, with distributed and remote production models becoming more established as broadcast workflows, the MPA1-MIX-NET features comprehensive web and SNMP support. Its built-in web server and integrated Ethernet connection are designed to enable remote configuration and operation of networked units via a web browser, whilst SNMP integration enables a broadcast control system to automate configuration changes, TSL reported. 

“The broadcast environment is constantly evolving and the expansion of the MPA1 family gives broadcasters the opportunity to choose the interface that best suits their needs,” says TSL’s products and technology director, Mark Davies.  “The range offers support for ST 2110, 3G/HD/SD-SDI, Dante, MADI, AES and analogue interfaces, in both solo and mix versions. As manufacturers it’s our job to stay connected with our customers and ensure we support them as their workflows continue to change, with no compromise in performance.”

The transition to audio over IP over the past decade has revolutionized the broadcast industry, bringing added flexibility and improving quality and options for the viewer. That progress, however, has not come without its concerns as media companies try to keep up with consumers who are viewing content on myriad devices.

In our latest free TV Tech Guide to Audio, we hope to lessen that anxiety by taking a look at how audio professionals are tapping into that flexibility that AoIP brings to our industry and the approaches taken to maximize the consumer audio experience. 

NEW BERN, NC—At this year’s NAB Show, April 23-27 in Las Vegas, Wheatstone is introducing several new AoIP-based audio consoles plus an upgrade to its Blade 4 access unit.

Tekton 32, Wheatstone’s latest AES67 and WheatNet-IP audio networked TV console will show for the first time at show. Tekton 32 interfaces with all major production automation systems through a unique control interface for tight integration of automation and mixing in one native IP audio environment. Tekton 32 has standard 64 channels (layered) and motorized faders tracked to automation so whoever is producing or directing, or doing both, can keep an eye on what the automation is doing and make adjustments as needed.

The AoIP console is also very easy to navigate for the occasional news report or sporting event that requires hands-on mixing. Tactile faders on the one hand and a touchscreen interface on the other make it easier for the busy producer or director to adjust EQ, fix levels and mix in feeds. All routing and control for the Tekton 32 is handled by the WheatNet IP audio network, an AES67 compliant and SMPTE 2110 supported IP audio network. If it’s on the network, it’s routable, programmable, and accessible – often automatically. For example, when a field reporter’s mic turns on, the correct mix-minus can be automatically sent back to the field reporter’s headset for IFB. 

The compact size of Tekton 32 is due to AoIP carrying much of the load that once sat on the console. Plus, by connecting routing, mixing and studio control through Ethernet cabling, AoIP opens up accessibility and gets rid of outdated wiring and layers of audio infrastructure. Tekton 32 is also WAN and REMI ready. Tekton 32’s WheatNet-IP audio network can scale from one location to several geographic locations across a WAN for use in REMI or other remote broadcast applications.

Also new is the GSX console surface, Wheatstone’s latest fully reprogrammable AoIP console and the newest addition to the WheatNet-IP audio network family. Wheatstone’s flagship LXE console surface, introduced in 2016, was the first completely customizable control surface for IP audio systems. 

The GSX AoIP surface features:

• Scriptable knobs and controls for customizing by show, talent or studio. Customize once and set it or quickly re-configure controls and displays for any purpose or application using Wheatstone’s ConsoleBuilder™ software.
• Up to 32 input channels with as few as four physical faders, or any combination that fits the studio size and function needed.
• Metering on-screen instead of on the console for a low-profile workspace that lets talent focus attention where it’s needed.
• Tactile surface on the one hand and touchscreen interface on the other for the best of both worlds. Faders and cue events on the surface. Pinch and drag EQ settings from the touchscreen.
• Modular design. Configure as a drop-in or tabletop console surface, or split into fader wedges in separate rooms connected via WheatNet-IP audio networking for fast and easy talent and show collaboration.
• Remote operation. Optional standalone virtual mixer or remote mixer that mirrors the physical surface offers an independent, yet shared user experience.
• Optional Automix, Layers, ScreenBuilder™, Smart Switch panels and IP accessories. Add any or all at any time to adapt the GSX to evolving needs.
• Empowered by WheatNet-IP, a complete intelligent network of connected elements, audio tools, and third-party products and applications.

Wheatstone has also added new audio tools on its AoIP network. This latest AoIP unit includes audio routing, control, codecs, processing, mixing, operating system and NMOS/AES67 interoperability in 1 RU. Blade 4 can be integrated into any new or existing WheatNet-IP network and includes:

• Selectable Opus, MP3 and AAC codecs for integrating workflows from remote venues or home studios into the studio operation as needed. All codecs are routable in native AoIP; no additional studio hardware required.  
• Built-in OS for running customized scripts and specialized software, metering apps and virtual interfaces.
• AES67 compliance, from .125 ms to 5 ms packets, for a wide range of interoperability with other AES67 devices and networks.
• Support for SMPTE ST 2110, including the NMOS discovery standard for AES67 and next generation television networks.
• Dual Ethernet ports available on every Blade 4 for failsafe redundancy.
• Integrated audio codecs, processing, mixing and operating system in one native AoIP environment for resource sharing.
• Two separate audio clip players, enhanced to play compressed or uncompressed audio files from the built in USB ports to virtually eliminate memory storage issues.
• Full AoIP I/O and intelligence in one unit for routing audio, mixing sounds, processing feeds, and controlling mics, consoles, and other studio appliances. Blade 4 has all the standard Blade features, including two 8x2 stereo utility mixers for online mixing of sounds or segueing remotely between feeds; routable stereo processor with parametric equalizer, compressor and limiter; and 12 universal logic ports plus 128 software LIO ports, programmable as inputs or outputs, and routable through the network.
• Codecs, software apps, mixing and audio processing, plus AoIP routing, control and interoperability in 1 RU for reducing rackroom real estate and associated cooling, cabling and other expenses.  

Wheatstone will be in booth N2631. For more information on the NAB Show, visit nabshow.com/2022.

LAS VEGAS—Sound is part of the many different aspects of broadcasting that will be featured at the 2022 NAB Show. Two elements in particular—immersive/personalized audio and intercoms—will attract a lot of attention in Las Vegas.

A trend that is still in its relatively early days is immersive and object-based audio (OBA). Both of these, which come under the general heading of “next generation audio” (NGA), have been discussed and promoted as “the next big thing” to hit broadcast television for at least the last decade. 

Dolby Atmos
This year will mark a decade since the first film in Dolby Atmos—Disney’s “Brave”—was released in cinemas, according to Mathias Bendull, vice president, Living Room, for Dolby Laboratories. “It’s incredible to see the progress we’ve made and the growing excitement from consumers and the industry demanding immersive sound experiences brought to life by spatial audio,” he said.

Today the world’s top streaming services—Apple TV+, Disney+, Netflix, and many others—deliver their most-watched movies and streaming shows in Dolby Atmos (and Dolby Vision) and Dolby Atmos devices are widely available across various price points and form factors from home theater systems to smartphones and TVs, Bendull said. 

With Samsung’s recent announcement that it would support Dolby Atmos in its upcoming Micro LED and Neo QLED TV, this means all major global TV manufacturers are now delivering TVs with Dolby Atmos, according to Bendull, who added that a majority of these TVs in North America also support ATSC 3.0 tuners, which will provide consumers access to NextGen TV delivered via Dolby AC-4.

“Consumer interest in Dolby Audio technologies, such as Dolby AC-4 and Voice+, has also shaped how broadcasters promote the benefits of NextGen  TV,” Bendull said. “This includes the recent NextGen TV holiday campaign, which aired commercials in participating ATSC 3.0 markets promoting the features of Dolby Audio, such as improved dialog audibility enabled by Voice + and consistent loudness.” 

Dolby is also teaming up with Pearl TV to amplify these messages at the NAB Show and through consumer education and retail point of sales initiatives,” he added.

Personalization & Immersive
On the horizon, the benefits of personalized audio features like home and away commentators, multiple language support, and audio description for 5.1 and Dolby Atmos are being explored by key industry players jointly with Dolby.

There is the view, from institutions such as Fraunhofer IIS—the main developer of MPEG-H 3D Audio—that the personalization aspect of NGA is the more compelling and necessary feature, rather than immersive sound. Christian Struck, senior product manager for audio production for Lawo, comments that the current trend appears to be creating presentations—in other words, “audio stems”—that can be used for different applications whose volume levels are set by viewers at home.

“A stem-based approach means that more channels and busses are needed than for a 5.1 setup,” Struck explains. “This means the ability to set channel levels for a variety of presentations becomes paramount and a flexible array of monitoring options is required.” 

On the subject of immersive audio, Struck describes it as “the perfect complement to 4K picture quality” and says it is being increasingly demanded by rights holders. “The main features for audio consoles in an immersive workflow, such as high channel counts and the bussing, monitoring and mixing infrastructure to support them, will become available in 2022.”

In terms of greater capacity on mixing consoles, at this year’s NAB Show, Lawo will be showing a 48-fader version of the mc²36 at the booth in the Central Hall. Other introductions include a software version for the mc² range, the A_UHD Ultra-High Density IP audio engine and new software features for the V_matrix routing, processing and multiviewing platform.

While sport and drama have fully embraced immersive audio—for future-proofing post-production if not for transmission at this time—there are areas that do not appear immediately well-suited to the technology.

“Our ‘bread and butter’ is TV news and it will be some time before that sector gets into the immersive environment,” comments Phil Owens, senior sales engineer at Wheatstone. Of personalization he adds, “There are a lot of levels to that. You can pick and choose different channels for things like second languages. But that’s not really immersive audio.”

At its booth in the North Hall, Wheatstone will launch Tekton 32, its latest audio over IP (AoIP) console for TV. The networked console is based on the company’s WheatNet-IP protocol that is aimed at smaller, local TV stations, which are either installing automated production systems or downsizing staff. It has 64 channels, which are layered, and motorized faders that can be controlled by the producer or director through the automation system.

Also on the subject of IP, a highlight at Calrec's booth will be a demo in which three independent consoles will be operated from a fully redundant pair of ImPulse cores; a 48 dual fader Apollo console, a 40 fader Artemis console and a headless console running Calrec Assist on a PC. The ImPulse DSP features native SMPTE 2110 connectivity and is compatible with the Calrec Assist web interface as well as Calrec’s Apollo and Artemis consoles to provide a simple upgrade path for existing Calrec customers moving to an IP domain.

It also provides 3D immersive path widths and panning for next-generation audio with height and 3D pan controls, flexible panning and downmixing built-in.

AoIP for Comms
IP is now firmly established in most areas of broadcast audio, from mixing to networking to distribution and contribution links. Another area that is now exploiting the full potential of AoIP is communications. 

The major intercom manufacturers—Clear-Com, Riedel and RTS—each has its own take on the technology, while other, smaller developers, or those entering this market more recently, have put their own spin on comms through IP. These include Green-GO, Glensound, Sonifex and AEQ, all of which will be exhibiting at the show.

Clear-Com, which will be exhibiting in the Central Hall, began investing in IP technology during the mid-2000s. Product Manager Kari Eythorsson explains that this was primarily to add remote connectivity for large comms systems in an efficient way. This, of course, proved beneficial during the height of the pandemic when production teams were either operating remotely within a broadcast center or working from home.

“In TV and film production, there was a need to build bubbles for people to work within,” Eythorsson says. “It was possible to reduce the number of people in a bubble [by connecting] with simple wireless systems.” He adds that the AES67 interoperability standard has allowed for expansion of IP systems, while virtual intercoms were facilitated through linking key panels, computers or smartphones over Wi-Fi, LTE or 5G connections.

Riedel also saw IP and remote communications become more in demand because of COVID-19, with the creation of hybrid environments.

 “Due to remote and virtual productions, as well as hybrid workflows, the IP connected intercom is becoming a new normal or a new requirement in projects and applications,” comments U.K. Sales Manager Nacho Lee. Despite the growing ubiquity of IP intercoms, Lee adds that more established technologies, such as matrices, still have a place in comms setups.

Audio may be a smaller percentage of the companies at exhibitions like the NAB Show but it is certainly making an impact with technologies that are significantly changing both the way people work in broadcasting and what TV services can offer their viewers. 

LOS ANGELES—With the growing adoption of IP networking in broadcast facilities and the downward pressure on production budgets, audio mixing consoles are entering a new era, one in which the board may be out of sight—indeed, miles and miles away—and may have no faders, or even an operator.

So what do customers now expect of mixing product manufacturers, and what is the likely next step in the evolution of the broadcast console?

“It seems like consoles have to do everything and cost half as much as they used to, these days,” says Wheatstone Senior Sales Engineer Phil Owens, who adds that U.S. stations essentially fall into three categories. Typically, the station needs a board that addresses the needs of the board ops, or they have some dayparts manned and others automated, or the station is fully automated.

“For the U.S. market in particular, a console has to be easy to drive,” he says, with a relatively simple first-layer user interface. “But maybe the layer just below the simple user interface gives you all the tools that an audio hotshot would want. The consoles that I’m primarily talking about are [Wheatstone’s] Strata 32 and the IP64—they share these same characteristics.”

STANDARD LIMITATIONS

On the topic of networking, Owens adds, “There are the SMPTE ST 2110 standards that will ultimately be embraced by pretty much everybody, so any board these days has to play nice with AES67, because AES67 is the transport stream for 2110.”

But Owens also predicts that AES67 will never reach the point where it can provide the necessary transport discovery, control, and logic that a proprietary network does, although NMOS will make connection management easier. Systems will always need to be able to interoperate with third-party devices via AES67, he says, noting that the company’s WheatNet-IP network handles the AES standard.

“But AES67 will never be the glue that holds the whole infrastructure system together,” he says. “That will always be a proprietary network.”

Many of IP’s benefits are currently more obvious on the video side of things. “Where you interface with products that are being made by a company in the video space, that’s where AES67 and 2110 tend to come in, said Martin Dyster, vice president, business development-TV, TV Solutions Group for the Telos Alliance. “Then when you’re connecting to products from other audio companies around the control room and the studio floor, that might be where you see Dante more.”

While more prevalent in radio facilities, Telos recently launched a new console—Quasar—for its Axia product range that is attracting attention in TV markets, Dyster reports. The entire Axia range, in common with all brands under the Telos umbrella, are fully AES67 compliant, he notes. Indeed, the AES standard evolved out of the company’s Livewire protocol, introduced in 1999, and RAVENNA.

Telos was involved with Notre Dame’s Martin Media Center, one of the first all-IP facilities to be built, where Axia Fusion consoles are handling TV production, with an Axia backbone connecting over AES67 to an Evertz EQX routing system. Livewire+AES67 connects the various campuses, alongside video-over-IP. “So we can stay pretty much native, and with Dante now embracing AES67 and our ability to connect to that, using SIP discovery and advertisement, that puts our products in a very strong place that I think is probably a little bit unique,” says Dyster.

CONSOLE VIRTUALIZATION

Customers are generally either happy with their present Calrec Hydra2 network, or are taking a gateway or hybrid approach, integrating Hydra2 with islands of IP to overcome the limitations of baseband, or simply familiarize themselves with IP technology, observes Dave Letson, vice president of sales for Calrec.

“We have about 10 installations where there is a Hydra2 console with our AoIP gateway unit connecting it to a 2110 environment,” he said. ‘They’ve got the best of both worlds. We’re able to maximize all the resources from a router or from the video architecture into the [Calrec] audio network.”

In addition to driving the use of REMI or at-home remote production workflows, AoIP has enabled “console virtualization,” which, hand-in-hand with a general desire to reduce production budgets, is beginning to enjoy more widespread adoption.

“I’ve been to a lot of facilities in the last 12 months where a physical surface was not required or was gathering dust because everything is either virtualized or is being driven from the vision switcher,” says Dyster. “I see that model now all the time, particularly in the U.S., at news affiliates, where you don’t see a physical console.”

Letson reports that one U.S. broadcaster is using Calrec’s Type R as a virtualized solution, with no control surface, connecting it to the station’s automation system at a fully-IP central hub. Calrec’s RP1 remote production unit supports the creation of local IFBs at a remote studio.

“That’s an interesting workflow, because you’ve got two sides of the virtual world,” Letson said. “We never saw those products working alongside each other for local news, but for that customer it works really well. It’s great for a local news production environment because they get to reduce some of the key staff. Some of the key staff are aging out, so you don’t have the same level of staffing that you used to have.”

Owens is seeing similar workflows in more localized situations, where two or more call-letter stations share a building with separate control rooms but a single set.

“Instead of having a standalone audio board you have a networked appliance that is fully routable,” Owens said. “At 5:00 you can route all the ABC sources into it and at 6:00 you can route the CBS sources into it. Either control room may need to grab certain shared resources, so the network aspect of the new consoles becomes more important,” says Owens.

The next step in console evolution is likely to encompass features for immersive audio production. Broadcasters are currently using 5.1 consoles for immersive productions, but, says Letson, the logical next step is to develop new metering, monitoring and other functionality.

But with so many immersive standards in play worldwide, from 5.1.4 to 22.2, anyone providing an international mix will need to generate multiple deliverables. “I think that’s where the tools will have to go next on consoles,” says Letson. “That’s part of where we are with ImPulse,” Calrec’s new processing core. “It will have those tools built-in.”

NEW YORK—The Audio Engineering Society will receive a Technical & Engineering Emmy Award for its work with audio over IP, sharing the award with six partners who were involved in developing the AES67 standard: ALC NetworX, Audinate, Kevin Gross, QSC, Telos Alliance and Wheatstone.

The award is for “Development of synchronized multichannel uncompressed audio transport over IP networks,” and will be given in a ceremony at the NAB Show at the Wynn Encore on Sunday, April 19. The Technology & Engineering Emmy Awards actually are given for developments or standardization in engineering technologies that affect television.

AES67 is a protocol that established a standardized language for audio transport. AES noted that its AES67 standard for high-performance streaming audio-over-IP interoperability was introduced in 2013. It stated: “AES67 compliance allows audio content interoperability between the proprietary IP-based audio networking protocols developed by the Emmy co-winners: RAVENNA, Dante, Q-Sys, Livewire+ and WheatNet-IP.”

AES Fellow Kevin Gross led the AES67 Standards effort and is the chair of the AES Technical Committee on Network Audio Systems.

In the AES announcement of the award, Gross was quoted: “The improvement from audio networking born in the mid-1990s to new IP-based solutions emerged as a simultaneous invention from the honored companies. While collectively this represented a technical improvement, interoperability was not addressed until the AES initiated the X192 project on audio interoperability.”

He thanked the late Steve Church, Rich Zwiebel, Philip Lawo and Andreas Hildebrand as leaders of companies who “understood the potential for a standard to take audio networking to the next level,” and thanked then AES Standards Manager Mark Yonge for mentoring the process.

AES Executive Director Colleen Harper said AES67 “fundamentally changed the broadcast audio landscape and paved the way for recent similar developments for video.”

NEW YORK—AoIP continues to advance, as reflected in the audio consoles that were released at the 2019 NAB Show.

Wheatstone rolled out a new console that packs 64 channels and native IP audio networking into a 40 inch frame that fits most television applications and budgets under $75,000. The Strata 32 targets newsrooms, remote vans and sports venues with dedicated faders for eight subgroups and two masters along with 32 physical faders that can be layered for 64 channels. It integrates seamlessly with all the major production automation systems and comes with IP audio mix engine and optional stagebox.

The company also introduced the Virtual Dimension Three virtual mixer as a standalone user interface into its WheatNet-IP audio network. Virtual Dimension Three can be used anywhere there’s a PC touchscreen or several touchscreens connected over the audio network. Similar in feel and function to the popular Dimension Three hardware surface, Virtual Dimension Three includes familiar buttons, knobs and multitouch navigation and menu-ing for adjusting EQ curves, filtering and other custom settings.

Virtual Dimension Three comes with a rackmount mix engine to handle mixing and processing as part of the Wheat- Net-IP audio network, which provides direct connectivity into major production automation systems.

Ross Video, Grass Valley and Sony have a longtime vendor partnership with Wheatstone’s WheatNet-IP audio network, making for a fully integrated user experience between automation and console functions.

“Automation and virtualization are fundamental to being able to produce more content,” said Wheatstone Senior Sales Engineer Phil Owens. “With Virtual Dimension Three, we’re complementing what is being automated in the control room with the easy accessibility of a virtual interface so that operators can make immediate, precise adjustments as needed.”

The AES67-compatible WheatNet-IP audio network is a complete IP audio ecosystem of consoles, talent stations, I/O units, and accessories.

Wheatstone also introduced a new AoIP appliance to allow users to seamlessly share full studio operation between facilities, sports venues, and other sites in separate locations. The SwitchBlade is a WheatNet-IP audio network appliance that includes AoIP logic control, SIP connectivity and codec bandwidth optimization—all critical for being able to produce content at a sporting or news remote.

SwitchBlade extends the AoIP network beyond the studio walls and lets the operator remotely adjust EQ, dynamics, and turn mics on and off at a remote location from the main studio several miles and time zone’s away. SwitchBlade has two ethernet connections, one for connecting to a SIP service provider or SIP-enabled PBX phone system and the other for connecting directly into the WheatNet-IP audio network. It comes with major codecs, including 256 Kb/s stereo Opus and G.711, for high quality program distribution between studios, networks, and affiliates, news gathering or sports venues.

“Not only will it carry the audio, it carries the control, which means you can send and receive router commands, automation control, and even fader levels across the two locations,” said Jay Tyler, sales director for Wheatstone. ”This is a real game changer because Switchblade finally makes it possible to monitor each point of the audio chain and switch audio locally from network operation centers around the world.”

Using WheatNet-IP’s Application Control Interface (ACI), the SwitchBlade offers up to 24 modules that show up as sources/destinations in the WheatNet-IP NAVIGATOR software, and are therefore available on every WheatNet-IP console surface and monitor selector in the system.

SIMPLE UPGRADE PATH

The most significant difference between Calrec’s new ImPulse and the company’s previous products is that it is built on a native IP backbone, with AES67 and SMPTE 2110 connectivity, according to Dave Letson, vice president of sales for the company.

“ImPulse illustrates a clear direction for Calrec’s future development,” he said. “It’s compatible with existing Apollo and Artemis control surfaces, providing a simple upgrade path for current Calrec customers as they transfer to IP infrastructures.”

Up to four DSP mix engines and controls systems can run independently on a single core. ImPulse sports an AoIP router which supports NMOS discovery and connection management, and mDNS/Ravenna discovery. ImPulse provides 3D immersive path widths and panning, with full monitoring and metering, height and eD pan controls. Paths of all widths can co-exist within a mix and be routed to and from one another with flexible panning and downmixing built in.

SMALL CONSOLE, MORE FADERS

Lawo bumped up the fader count on the third generation of its mc²56 IP audio production console this year. Up to 144 faders are now housed in this small size console. The dual fader option incorporates Lawo’s LiveView thumbnail preview feature, which presents thumbnail previews of associated video streams directly in the fader strips.

This console is optimized for the IP-video production environment, featuring native support for SMPTE 2110, AES67/Ravenna, Dante and MADI audio streams. The mc²56 has adopted the SMPTE 2022-7 standard for Seamless Protecting Switching (SPS), delivering dual-redundant IP-network links to its Nova73 routing engine. Built-in loudness metering is standard, with full loudness control adhering to ITU 1770 (EBU/R128 or ATSC/A85) specifications.

For mobile productions the scalable DSP performance with temporary licenses can turn CAPEX into OPEX.

Lawo also rolled out its new UHD Core, a network-based, software-defined audio DSP engine. Utilizing the IP network as an extension of the console core’s backplane, the UHD Core can be located anywhere on the network. Its ultra-high processing density—with 1,024 fully featured mc² DSP channels—can either be utilized by a single mc² console or shared by a maximum of four boards.

ULTIMATE DESKTOP MIXER

Audio pros of a certain age remember when Mackie first released a tiny mixer—the 1604—that revolutionized the home recording industry. With the introduction of SiX, billed as “the ultimate desktop mixer,” SSL may have brought this revolution full circle.

SiX sports a pair of recording channels with SuperAnalogue mic pres, a one knob version of the classic SSL Channel Compressor, a new two-band Channel EQ, inserts and 100mm faders. There is a two-knob version of the legendary G-Series Bus Compressor on the main mix bus and a Listen Mic Compressor on the Talkback.

“With over 30 years’ involvement in the design of SSL consoles, when developing the concept of SiX, I thought hard on what our users appreciate about our larger consoles; what helps their workflow and delivers quality results for them,” said Niall Feldman, director of new products for SSL. “The big challenge was how to deliver those values and features in a compact product. The resultant SiX mixer is one of our proudest achievements.”

SSL also launched its S500m console, which provides all the flagship features of the company System T S500 console in a form factor that is more than 25% lighter, specifically designed for OB and flypack applications where weight and portability are key concerns.

“The complexities involved in today’s major sports and entertainment events means our OB partners still require broadcast consoles with a high specification, yet be robust and easy to transport” comments Tom Knowles, broadcast product manager for SSL. “The S500m brings the portability and added flexibility our clients need for a multitude of broadcast environments, making it the ideal choice as a flypack or transportable OB option.”

SSL also released their Dynamic Automation Software (DAS) at NAB. Designed to work with all System T broadcast production consoles, DAS expands System T’s capabilities.

“Dynamic automation has become a necessity for many of our major broadcast clients, for both live to air and complex television post production tasks,” Knowles said. “By offering this as a software option our clients can adapt their System T capability as they need it.”

COMBINES MIXER AND SURFACE

For smaller facilities and similar-sized budgets, Telos rolled out its Axia iQx AoIP console at the show. The compact mixer combines the mix engine and surface into one unit, enabling quicker setup. iQx is AES-67 compliant and can also support SMPTE 2110-30. Also, there are no limits to the number of sources and connections users can access on the network.

iQ is Telos’ radio console system, that can be used to build custom consoles of sizes from 8 to 24 faders, however it could also be installed as a reliable standby for TV audio production needs as well, according to Marty Sacks, vice president, sales and support for Telos.

“The iQ family can be used as a backup for larger desks in a production environment,” he said.

LOS ANGELES—As AoIP transports have coalesced around the AES67 interoperability standard over recent years, IP communications equipment manufacturers have introduced products that extend far beyond simple intercom functionality. No longer confined to restricted geographic areas with limited partyline functionality, the latest generation of IP comms gear has become a gateway to the LAN or even the WAN, offering worldwide connectivity and the ability to transport all kinds of data, not just audio, and certainly not just voice communications.

MATRIX-FREE

Last year, Telos Alliance launched its Infinity IP Intercom system, which converges voice communication and contribution audio on a single IT backbone, employing the latest standards-based VoIP and Livewire+ AES67 AoIP transport. Infinity introduced a matrix-free paradigm to broadcast communications that enables the system to be scaled up without worrying about how many ports are available. Infinity additionally integrates into existing analog, AES, SDI, and MADI systems via an AoIP interface that could include the manufacturer’s xNode baseband-to-IP interface line.

More recently, Telos introduced Infinity Link, an OPUS codec-based software product that converts WAN-side VoIP to LAN-side Livewire+ AES67. The royalty-free OPUS codec offers manually and auto-adjustable bitrates that are optimized for voice communications over the Internet and for storage and streaming applications.

The way that Infinity Link encompasses VoIP as part of the entirely matrix-free AoIP solution is unique, according to Martin Dyster, Telos Infinity project director.

“With a simple license key, each Telos Infinity device, whether a beltpack, master panel, or expansion panel, can host a group of Infinity Link codecs,” Dyster said. “This enables any IP audio path within its own network to connect across WAN to a Link-equipped codec at any remote location, bridging the local system to the outside world via its own embedded processing engine.”

TUNING OUT AMBIENT NOISE

Riedel Communications has introduced a unique wireless comms service aimed specifically at sports officials. Initially developed with German Football League (DFL) to address their requirements but applicable to many sports, Riedel’s Bolero S wireless hardware connects via AES67 to a local Riedel Artist frame, which interfaces with the Riedel’s Remote Operations Center in Wuppertal, Germany.

At the ROC, engineers at Riedel’s newly managed services group monitor audio quality, RF performance, and battery life while also adjusting talk and listen levels on the officials’ voice-activated headsets in real time as ambient noise levels change.

“This was the result of great synergies between Riedel, DFL and the refereeing department of Deutscher Fußball-Bund,” said Riedel’s Corporate Business Development Manager, Jacqueline Voss. “A stadium with 80,000 cheering fans, like Signal Iduna Park in Dortmund, is a very demanding environment for clear communications.”

The company is reportedly now in discussions with several North American leagues about adopting the service.

The Artist-1024 node packs 1024 non-blocking ports into a 2RU box that can be fitted with up to eight additional software-definable Universal Interface Cards (UIC). These new interface card combine networking, mixing, and management, and can be configured to act as an AES67 or MADI subscriber card, or as an Artist fiber/router/processor card through Riedel’s Director configuration software. The integral mixer on each subscriber card can be scaled from 8 to 128 ports per card and can access all 1,024 ports of the Artist backbone.

MAKING THE MATRIX MORE ACCESSIBLE

RTS recently launched its ODIN OMNEO digital intercom matrix, touting the new product as the only multiformat intercom matrix that works with all industry-leading standards, protocols, and connection types, including AES67, AES70, ST 2110, VoIP, G.711, G.729, G.722, Dante, and 4W analog. It also connects directly to partyline systems, the company said.

The feature set and compact form factor of the 1RU device were designed to make a matrix solution more accessible and easier to use than previously, according to the company, widening the potential IP-based communications user base. ODIN also provides a path for system expansion for smaller users who want to upgrade existing RTS systems to the latest technologies, the company states.

ODIN supports RTS IP-based ROAMEO wireless systems and KP-Series keypanels and users can flexibly define ports to use any of the available connector types. Providing a path to scale up the system, a single ODIN can grow from the basic 16 ports to a maximum of 128 ports and as many as eight ODIN units can be connected via an optical Inter-Frame Link to create a single matrix with up to 1024 ports. Up to 16 analog keypanels may be connected.

Joe Watson, staff engineer for ATK Versacom recently used ODIN to provide comms for “American Idol” auditions. “Everything I needed fit in one small 13-space rack—a huge improvement compared to my multiple-rack setups previously,” he said. “This makes ODIN a great fit for flypack operations.”

EXPANDING IP CAPABILITIES

Several years ago, Clear-Com introduced its LQ Series IP interfaces, compact devices that enabled users to extend their intercom footprint by connecting virtually any type and brand of intercom or audio device via AoIP, SIP, GPIO, 2-wire or 4-wire. The interfaces are a cost-effective method for connecting visiting systems or ad hoc users.

Clear-Com’s professional intercom communication portfolio now encompasses a broad range of IP-based products, including matrix, wireless and mobile IP solutions for all kinds of production workflows, including remote production.

“The breadth and depth of our ever-evolving product line proves how far Clear-Com has come with IP, building on our unrivalled expertise and industry experience to create solutions for any application,” said Clear-Com President Bob Boster.

At the NAB Show, the company further expanded its product line with the addition of the new V-Series Iris intercom Panel, which provides Eclipse HX users with a low latency AES67 AoIP connection. The V-Series Iris Panel can monitor and send communications over three concurrent full-duplex uncompressed audio IP streams, enabling systems to deliver high quality, uncompressed AES67 audio from user to user with significantly reduced latency. Users can deploy up to 64 Iris panels for each high-density E-IPA audio-and-intercom-over-IP card fitted. The card is natively AES67 compliant.

Clear-Com’s IP products also include its FreeSpeak II wireless intercom system. The FreeSpeak II IPT Transceiver features AES67 compatibility, low latency signal distribution, high radio performance, and high audio bandwidth, enabling FreeSpeak II wireless beltpacks to be deployed across a user’s LAN. The IP Transceiver connects to an AES67-compatible IP router and to Clear-Com’s Eclipse HX system via the E-IPA card.

Last year, Clear-Com unveiled the latest version of Agent-IC, a mobile app Apple or Android mobile devices that connecting securely to core intercom users across multiple IP networks over 3G, 4G and Wi-Fi, a potential boon to outside broadcasts or productions where crews are spread across large areas.

Webinar – IP Audio Systems

 Standards such as AES67 and SMPTE ST 2110-30 have both appeared within the past three years, and are already making significant impact on the industry. With IP-based audio systems, hundreds of high-quality, 24-bit audio streams can be transported using a single, inexpensive gigabit Ethernet connection, thereby greatly reducing the cost and complexity of multichannel audio production.

TV Technology will be presenting a live webinar at 2:00 pm EST March 21st that will begin with an overview of IP audio technology. The new standards will then be reviewed, followed by a discussion of design tips that can promote interoperability between various IP audio systems.

Webinar topics will include:

• Fundamental concepts of IP Audio
• Understanding AES67 and SMPTE ST 2110-30
• Interoperable IP audio network design tips

Click here to register and learn more. 

LOS ANGELES—The universe of AES67- compliant products has expanded over recent years and with the interoperability standard now published in the SMPTE 2110 standards suite has become the “Rosetta Stone” of audio-over-IP. But while digital mixing console system products were among the first to adopt AES67, to what extent are end-users networking compliant products? What barriers to adoption remain, and what can be done to promote more AES67 network implementations?

ALL IP

“In the TV market, AES67 interoperability is part of almost every client conversation,” said Martin Dyster, vice president of business development-TV, TV Solutions Group, The Telos Alliance. Proof that AES67 is ready for primetime can be seen at University of Notre Dame Martin Media Center, a benchmark for what is possible in an all-IP, multivendor environment, where his company supplied the console and routing pieces, Dyster said.

Across the campus-wide media production environment, says Dyster, “All video and audio are transported as IP from the cameras and mics to PCR, and in the case of the Telos Alliance Axia Fusion consoles, there’s not a physical router in sight. Everything is routed at switch level, so it truly is a system achieving what was intended with AoIP all along.”

The installation includes Evertz core video and control elements. “The interchange of around 450 AES67 streams between it and the audio production system is seamless,” Dyster says. “Other vendors in this installation include Riedel, who supplied an AES67-equipped Artist system. Other examples where we’ve connected at AES67 level include products like the Genelec 8340 IP monitors—but any AES67 compliant product should work fine.”

AOIP IS THE GOAL

Don Bird, vice president of Business Development and Marketing for Lawo North America, agrees that AES67 is a basic requirement in almost every customer project. “In some cases, as a natural subset of their request to deploy a complete ST2110-compliant infrastructure, but even in those projects involving an upgrade of existing facilities where AoIP is the goal and the rest of the production pipeline is going to be migrated to IP over time,” he says.

Lawo has been providing AES67 capabilities across distributed and remote production architectures as well as in local studio environments for some years now, according to Bird. “This is nothing new at this point, as customers clearly recognize the savings in cost, flexibility and efficiency of operation.”

Phil Owens, senior sales engineer, for Wheatstone in New Bern, N.C., has observed less enthusiasm for AES67 thus far. “Customers are primarily concerned with their central infrastructure,” he says. “AES67 tends to address add-ons, in most cases. This will change in the TV market as SMPTE 2110 and its audio component, SMPTE 2110-30, become more prevalent.”

Owens has primarily seen client interest in interfaces with a live sound component in a system, and interfaces with some AES67- or Dante-capable intercom systems. “And we have seen smaller local studio implementations, such as interfacing with Dante-equipped mic preamps via AES67,” he reports.

“We are currently working on two university projects that have an auditorium equipped with a Dante-equipped live sound board tied into their broadcast facility via AES67,” adds Owens. “Another university has expressed interest in interfacing a Wheatstone system with an RTS intercom using their Omneo protocol, which is in fact Dante; that will be an AES67 interface.”

Calrec Audio has supplied AoIP networks to several broadcasters for facility-wide installations, reports Dave Letson, the company’s vice president of sales. “More often, though, we are seeing pockets of deployment in POC or smaller applications, so the broadcaster or facility can cut their teeth and gain an understanding of SMPTE 2110 networks.”

The real benefits and savings will come from greenfield builds that can implement the networking facilities from the get-go, Letson believes. Thus, some manufacturers have developed products, such as Calrec’s H2-IP Gateway devices, to bridge proprietary IP infrastructures and create hybrid networks.

That said, Calrec consoles are being networked with products such as Sonifex’s AES67-based monitor pre-hear products and Grass Valley routers, says Letson. “Calrec’s AoIP I/O solutions allow any piece of third-party equipment that is AES67 compatible to talk to Calrec’s I/O boxes and enter the [company’s proprietary] Hydra2 domain.”

BARRIERS TO ADOPTION

Manufacturers almost universally note that AES67’s lack of discovery, control and connection management, which were never part of the standard’s brief, are a barrier to adoption. Lawo’s Bird observes, “We offer a range of products that enable us to provide all-AES67 network infrastructures for our customers, so we don’t really encounter any barriers in that respect.”

“AES67 is an audio-only interface that has to be set up manually by entering a number of stream parameters at both the send and receive ends,” says Owens, “or ‘semi-manually’ by using an SAP utility to advertise those stream parameters to the various endpoints. Control—logic events—has yet to be addressed, although yet another standard, AES70, is a possible solution.”

Letson points to a recent survey by Grass Valley that indicates that IP adoption is slower than previously forecast. Two-thirds of respondents stated a preference for a hybrid approach, with cost a major concern when considering a move to IP. “Cost is obviously a barrier unless you are already planning to replace equipment,” he says, including the costs to deploy completely new infrastructure and train staff, and costs incurred through disruption.

“A fear of the unknown and a feeling that AoIP is brand new and unproven” also militate against wider or faster adoption, Dyster suggests.

The Networked Media Open Specification [NMOS] is currently being finalized. The IS-04 part of that spec addresses discovery, and the IS-05 part addresses connection management, according to Owens. “NMOS will make AES67 much easier to set up and use,” he said.

Calrec, like many other manufacturers, is developing a stream manager, Calrec Connect, which will allow complex network information to be displayed and streams to be created in a user-friendly manner, according to Letson. “This helps to reduce the burden of training needed,” he said.

Bird noted the importance of ongoing training in fostering adoption. “Through involvement in associations like AIMS and various technical recommendation groups and standards bodies we put great emphasis on education and awareness,” he said. “We encourage any customers interested in deploying an AES67 infrastructure to have open dialog with their consultants, integrators, and equipment providers to verify that all components specified are fully supporting the standard in an interoperable way.”

At this year’s NAB Show, I was engaged in a discussion about audio over IP with Phil Wagner, recently named president of Apogee, when he mentioned that no one was really discussing how to merge the technology into existing television environments. My own columns have been pointed more toward implementing it into new builds.

THINGS TO KEEP IN MIND

There are really just a few key things to keep in mind when tossing AoIP equipment into the technology mix of a current broadcast plant, but with SMPTE ST-2110-based facilities coming online and AoIP beginning to manifest itself in a very physical sense, this seems like a good time to look at them.

Just as we’ve done since television audio became digital, everything in the plant needs to be referenced to the same master clock. This has traditionally meant providing either black, tri-level, word clock or AES reference (DARS), but network connected devices—surprise—look for their clock on the network, which means we now need to provide them with an IEEE 1588 Precision Time Protocol (PTP) clock, which has been referenced to the house master. In the past this might have been achieved with a master clock from the IT world, but broadcast device manufacturers now provide master sync generators that include PTP alongside standard reference signals. Reference remains critical because the audio going through those network cables is still digital, so nasty tics, pops or complete lack of audio is the result when the reference clock is missing or incorrect.

Choosing a specific AoIP technology can seem like a daunting task since incompatibilities remain even with the publication of the AES67 standard. Remember that AES67 is not an end-to-end solution but is a defined set of internet protocols that, if followed, will allow audio to pass from one AoIP device to another. The good news is that virtually all AoIP equipment manufacturers ship their newer products with an AES67 compatibility mode of some sort, which ensures that audio will pass when connecting a box with one AoIP technology to a box with a different AoIP technology.

The bad news is that the audio is all that is guaranteed. Sticking with a given AoIP technology, Dante, LiveWire, Ravenna or WheatNet for instance, provide a more end-to-end solution so that all AoIP equipment on the network is aware of each other and information can be shared between them. It also means having full control of those devices, allowing routing and management. Mixing AoIP technologies doesn’t preclude the possibility of doing any of these things, but the lack of information sharing between technologies can make it very, very difficult.

OPERATING IN AES67 MODE

Careful planning is the best course of action before heading down the AoIP road. Since AES67 is the PCM audio transport of ST-2110, any AoIP devices in the broadcast chain will most likely need to operate in AES67 mode, so it is necessary to determine what, if any, features are lost when switching devices to this mode. Since discovery, control and management are not part of AES67, it is also critical to determine how this will be done prior to adding AoIP devices to the plant.

As previously mentioned, sticking with one technology or manufacturer will solve this problem, but this may not provide all the necessary pieces. There are now some third-party software products that promise to make differing AoIP solutions work together despite their differences, but a demonstration of the software controlling actual hardware seems in order before committing to this.

A solid solution seems on the very near horizon however, and it is already part of the ST-2110 package of standards. Obviously, ST-2110 will need discovery and registration, connection management and control, so the Advanced Media Workflow Association (AMWA) Network Media Open Specifications (NMOS) IS-04 and IS-05 have been chosen to solve those needs for ST-2110 devices. This means that AoIP devices in television facilities will use AES67 for audio transport, IS-04 to locate each other, and IS-05 to connect. Actual implementation of these specifications will be through additional software, but this is the current solution planned for SMPTE ST-2110.

A temporary workaround to the lack of discovery, connection and control across all AoIP technologies is to build an AoIP system from a single technology, then isolate this AoIP island from the rest of the plant with the exception of converting signals going in and out of these rooms. This could work for an audio suite (or group of suites) or even live mix rooms where IO to the room is self-contained and does not need to interface with other IO other than for ingest and playout. Outfitting professional broadcast audio consoles (and some semi-pro models) with AoIP alongside SDI, MADI, AES, analog IO as part of the system’s configuration is becoming standard practice. Achieving the same thing in video edit suites and the greater facility will prove a bit more difficult, and will involve more interstitial pieces. But again, advance planning is key, and part of that planning should be looking toward the facility’s future and not just its current state.

Probably the easiest part of adding AoIP devices to a television facility is connecting existing audio and networked audio devices together. There is more to it than just plugging in Ethernet cables for the AoIP devices themselves, since they need to be set up properly on the network. The type of network and its particular setup will determine how complex this actually is. Yet when it comes to interfacing AoIP devices with traditional audio devices there are plenty of solutions available of all types.

Attention needs to be paid to the underlying technology and whether it has an AES67 mode, but not every piece will be part of the broadcast chain.

Jay Yeary is a television engineer who specializes in audio. He can be contacted throughTV Technologymagazine.

The first day of the IEEE Broadcast Technology Society’s 68th three-day Broadcast Symposium drilled deeply down into emerging “disruptive” technologies as they affect the broadcast platform.

INVASION OF THE SMART SPEAKERS

Heading the list was the rapid rise of “smart speaker” technology and their deployment in the consumer environment. In his presentation “The Broadcaster’s Place in the Smart Speaker Ecosystem,” the NAB’s Senior Director of Technology, Education and Outreach Brian Savoie noted that even though smart speakers were launched only about three years ago, their acceptance and popularity is really unprecedented.

[Read: IEEE BTS Fall Broadcast Symposium Gets Down to Business]

“The adoption rate has been very rapid,” said Savoie. “It’s likely to be faster than that of any other consumer device in history.”

He noted that the smart speaker is becoming a gateway for connecting with many services that consumers routinely use, and advised broadcasters that “Alexa is coming to the car” and they needed to make plans to get on that platform. “A hybrid voice-controlled radio was demonstrated at the Orlando Radio Show a couple of weeks ago. It’s coming.” He added some broadcasters could already be ready without knowing it. “If you’re streaming, you may already be on the platform.”

SPECTRUM SHARING, 5G, PIRATE BROADCASTERS, AND MORE

First-day “disruptive” presentations ran the gamut from methodology for sharing of 2025–2110 MHz spectrum between the U.S. Department of Defense and television ENG crews to 5G wireless broadband technology and its possible impact on conventional over-the-air broadcasting. Hybrid over-the-air/internet broadcasting was also on the radar, with one presenter providing information on initial testing of methodology for transmitting not only sight and sound, but also smell, taste, and touch content to provide a completely immersive experience.

Even the first-day luncheon keynote address followed through on the theme with a slightly different aspect of disruptive technology — the concept of storytelling — with Dolby Laboratories’ Chief Scientist Poppy Crum, describing how new and changing media technologies have the potential to change the way storytellers interact with their audiences, and even the storytelling methodology itself.

Activities wrapped up with a presentation on “Pirate Radio and FCC Enforcement” from Charles Cooper, director of the FCC’s Field Division of the Enforcement Bureau. Cooper stated that enforcement of pirate operations has a very high priority at the FCC, and noted that during the past year, 242 notices of unlicensed operation had been issued, and that the highest possible monetary penalty had been issued in the case of a Florida pirate operation.

“We also referred several cases to the federal courts for equipment seizure,” he said.

The conference continues on Wednesday with sessions on AM/FM digital-only broadcasting, ATSC 3.0 and UHD television, and connected car radio.

[Want more information like this? Subscribe to our newsletter and get it delivered right to your inbox.]

LOS ANGELES—Whether over standardized network protocols such as SMPTE ST2110 and AES67 or formats like Wheatstone’s WheatNet, Calrec’s Hydra2, RAVENNA, Audinate’s Dante, and others, audio mixing consoles are supporting remote television broadcast audio productions as they move in new directions. In sports broadcasts, especially, consoles are leveraging networks to implement a variety of applications, from at-home production to ensuring consistent audio quality at every connected mixer, to enabling remote control of, and set-up through, distant desks.

Glen Stilwell, audio operations manager for the PAC-12 Networks, which handles more than 450 at-home productions in a nine-month period each season, observed that IP audio networking is introducing efficiencies for remote broadcast operations. He hopes that new technology from console manufacturers will help him lower costs as the number of productions inevitably increases.

“With our development partners like Calrec, and their new RP1, we’re going to start eliminating the need to carry around big, heavy copper,” said Stilwell, who noted that all the schools in the conference have installed 10-Gig networks. The RP1 unit offers local DSP and an IP connection back to the plant where the mixer has full control of the remote inputs.

“We’re still precabling venues with copper mic cable, per season,” said Stilwell. “As we become more efficient and reduce personnel, we can’t spend the time to do that.” With devices such as the RP1, “We can put down either fiber or, over the long-term, build network drops in the field and just leave them forever,” he said.

PLAYING TOGETHER

But even with networking infrastructures in place, setting up AES67 streams between devices from different manufacturers is not yet as easy as it could be. Even using a common discovery protocol like mDNS/Bonjour, it’s currently necessary to log into a device using one brand’s web UI and create an AES67 stream, then switch to another brand’s web UI, log in, find that stream, and register to receive it.

According to Pete Walker, senior product manager for Calrec several companies are working on the problem—indeed, there is already a solution in the works. “NMOS [Networked Media Open Specifications] is going to take it to the next level,” Walker said. “You can use a central piece of software to control all your devices.” The initial NMOS tool will be IS-04, managing device discovery.

Walker says the protocol is still developing and Calrec doesn’t want to have to wait for it. “Calrec and others are looking at implementing cross-platform control systems, software that discovers all the devices on the network,” he said.

Calrec’s solution, “Connect,” will identify media streams and devices on the network regardless of their registration or discovery protocol. “You can filter, search, then drag and drop devices and interconnect them,” he said. “It visually represents all your streams and workflows.”

At this year’s three-part U.S. Open (Women’s, Senior’s, and Men’s) for Fox Sports, Senior Audio Engineer Dana Kirkpatrick leveraged Calrec’s Hydra2 network to QC the very large number of audio channels coming from the Shinnecock Hills Golf Club course in Southampton, New York. “We were feeding the router and six Calrec Brio consoles in the iso, two digital feature groups, and feeding another Brio, as well as a submix console, a Calrec Apollo,” Kirkpatrick said. “And I was creating two MADI streams for the world.”

The huge network enabled Kirkpatrick to achieve consistency across the attached consoles, he said. “The idea was that I would take everything from the golf course into the Calrec Artemis [in Game Creek’s Maverick remote truck] and EQ and distribute it. When the wind kicked up, I could adjust EQ and it would globally pass to all the mixers, so that the final product had the same EQ and the same gain structure.”

DOLBY ATMOS

Although some features need to be beefed up or even added to meet new production demands, the current generation of mixing console technology has enabled broadcasters in Europe to regularly generate programming, specifically for premium customers, in the Dolby Atmos immersive audio format for the past year or so. In the U.K., for example, all live Premier League soccer matches on Sky Sports, including a double-or even tripleheader on Sundays, have been produced in Dolby Atmos, as well as 5.1, since the start of the season in August 2017.

At a recent month-long competition hosted at multiple sports venues, U.K.-based freelance sound supervisor Pete Mercer produced both a Dolby Atmos mix and a 5.1 mix in a control room at the International Broadcast Center. For each event, Mercer received discrete feeds from the mixer in the remote stadium, including the outputs from a Schoeps 3D microphone suspended above the field of play, created a Dolby Atmos 5.1.4 mix plus six objects on a Lawo mc²96 console, and returned that mix to the competition location for encoding. He and his colleague, Felix Krückels, Lawo’s director of business development, in a second control room on a second mc²96, each mixed one or two games per competition day, Mercer reported.

The two mc²96 consoles were on the same network as the Lawo mc²56 (for stereo production) and mc²36 (for multifeeds) consoles at the competition’s 12 venues. “We could connect via a PC and Lawo MXGui software to check settings, re-patch signals, and even line up by ourselves,” he said. All audio was sent between the venues in each city and the IBC via Lawo’s Commentary system using Ravenna, according to Mercer.

Any console that supports multiple 5.1 buses may be used for Dolby Atmos immersive mixing. In Mercer’s case, the height component had no LFE or center channel information, so was, in effect, a 4.0 bus.

Mercer could monitor the 5.1.4 mix for the UHD feed via Dolby’s DP590 unit. But loudness metering of immersive mixes is still a work in progress and not yet available in consoles. However, said Mercer, “Having a separate value for the 5.1 and the 4.0 height was extremely helpful to make sure the height detail wasn’t too prominent or distant in the mix, especially when mixing extra elements into the 5.1 that didn’t appear in the 4.0 height.”

By now, you’ve heard that AES67 is part of the SMPTE 2110-30 standard and that all the major IP audio vendors offer this audio transport standard as part of their system.

The AES67 format will be useful for streaming audio between the control room and the master control and there’s good reason to believe that it will effectively eliminates the practice of HD/SDI audio embedding/de-embedding with video, and all the hardware that goes along with HD/SDI workflows.

There’s been a great deal of talk about AES67, but that is as far as it’s gone for most broadcasters – essentially a new standard still sitting on the dealer lot waiting for a test drive.

How easy will it be to commission AES67 in your plant?

We decided to take AES67 out for a spin to find out. Earlier this summer we did a trial run of AES67 through a large WheatNet-IP system staged at the Wheatstone factory in New Bern, North Carolina, during what we call a BLADEFest. (BLADEs are the I/O access units that make up the WheatNet-IP audio network). We do BLADEFests periodically to test our system under real-world conditions, and for this one, we added in a few AES67 devices while we were at it.

We added AES67 devices from Genelec, Ward-Beck, Dante, and Axia into the WheatNet-IP system of 12 mixing consoles, 62 hardware BLADEs (or I/O access units), 100 software BLADEs, talent stations, SideBoards, Smart Switch panels, and software including three different vendors’ automation systems. It was all tied together through Cisco and Dell switches.

We ran the system through a series of automated torture tests that included completely rebooting the system and verifying proper operation afterward. We’re happy to say that after more than 160 reboots, not a single connection failure or loss of audio occurred. We also learned a great deal about commissioning AES67 in a plant. Here are a few major findings.

Finding #1. AES67 specifies version 2 of the IEEE-1588 Precision Time Protocol, or PTP. For an AoIP system to maintain timing and stay synchronized with other AES67 devices, the system timing must be controlled by PTPv2. For that to occur there must be some device in the system that serves the role as PTPv2 timing generator to which all other devices slave their timing. Standardizing timing makes it possible to re-synchronize audio to video since every packet in the AES67 audio stream carries a time stamp. Once the PTPv2 clock is running, it’s possible to begin connecting AES67 devices to the network. 

Once the PTPv2 clock is running, the system is licensed for AES67 and it’s possible to begin connecting AES67 devices to the network.

Finding #2. Before connecting AES67 devices, map out an IP and stream multicast address plan with all devices on the same IP subnet. Each AoIP vendor has their own way of allocating addresses and a plan will assure there’s no overlap and that AES67 devices will be on the same IP subnet since multicasting does not normally cross subnet boundaries. Start with the AES67 devices that are least common or least flexible in specifying or changing multicast addresses.

Finding #3. When adding an AES67 device to the network, set the system sample rate at 48kHz unless you know the device sample rate. AES67 does not require devices to support 44.1kHz and many do not. You’ll most likely find this setting option and others in the admin software that comes with the network system. For example, the WheatNet-IP audio network uses Navigator, an interface screen of which is shown below. 

Finding #4. When adding an AES67 device to the network, pay attention to packet timing incompatibilities. WheatNet-IP uses 1/4 ms packet timing for minimum latency. Most AES67 devices also support 1/4 ms packet timing but some, such as Dante, do not. For those devices that do not use 1/4 ms packet timing, we enabled the AES67 1 ms Support option in WheatNet-IP Navigator, as shown below.

Finding #5. Some AES67 devices do not offer an easy way to manually manage streaming details, although these devices often can ingest these details in the form of an SDP file. In our case, we created SDP files by simply right-clicking on the desired source stream’s name in the Navigator crosspoint grid and opening a window that let us create the file. 

Above are a few sample SDP files from WheatNet-IP and Dante showing multicast address, packet timing, sample rate and stream formats.

Overall, commissioning AES67 in most broadcast plants should be a nonevent as broadcasters begin adopting the SMPTE 2110 suite of standards. 

Andy Calvenese is vice president of engineering for Wheatstone.

Editor's note, Finding #1 was updated July 30, per author's request. 

With the AES67, SMPTE ST 2110, AMWA NMOS and ATSC 3.0 standards and guidelines now largely in place, the inexorable march toward all-IP workflows continued at the 2018 NAB Show, with precious few new product introductions not offering some form of networking. New IP-enabled mixing console, interface and intercom products were in particular abundance, no doubt spurred by this new era of digital audio interoperability.

AUDIO MIXERS & INTERFACES

CALREC AUDIO debuted its Brio 12 compact 12-fader mixer, offering 12 physical dual-layer faders with additional virtual faders, 48 input channels and the same bus count as the Brio36, in less than 18 inches wide. New RP1 remote production unit features include a 2-band filter, 4-band EQ, expander and gate, compressor and sidechain EQ facilities, direct output for all remote faders, up to 5.1 wide, and remote auxes via Calrec Assist.

FAIRLIGHT, part of Blackmagic Design’s DaVinci Resolve 15 software suite, debuted an ADR toolset, 3D panners, shared sound libraries, support for legacy Fairlight projects, and built-in cross-platform plug-ins such as reverb, hum removal, vocal channel, and de-esser.

FERROFISH rolled out the PULSE 16 DX, a 16-channel, AD/DA converter with Dante compatibility.

LAWO unveiled its third-gen mc²56 console, incorporating features drawn from Lawo’s mc²96, in a compact, flexible and versatile form factor that address applications ranging from broadcast trucks and studios to live performance and recording.

NTP TECHNOLOGY introduced its new Dante/AES67 Penta 720 2RU modular audio interface with a variety of analog and digital interface options. The new Penta 721 is a 1U digital-only unit, with dual power supplies, that can be configured with various built-in options.

RME introduced its new Digiface Dante mobile audio interface, providing transmission of up to 64 Dante channels and 64 MADI channels via a USB 3.0 connection. The Digiface AVB mobile audio interface enables transmission of up to 256 network audio channels between a Windows computer and other AVB devices within an audio Gigabit network via a single USB 3.0 cable.

SOLID STATE LOGIC’S System T-S300 comes in two versions, 16+1 faders and 32+1 faders, supports Dante, AES67 and SMPTE 2110-30, and can connect to either a Tempest T25 (256 paths @ 48kHz) or a T80 (800 paths @ 48kHz) processor engine.

SONIFEX’S new AVN-PXH12 12x2-channel mixer monitor can simultaneously monitor/mix up to 24 RAVENNA, AES67 or AES67-enabled Dante sources in a compact 1U rack to a speaker/headphone combination.

STAGE TEC unveiled a preview of its Avatus IP mixing console, which features control and display via touch screens with color-coded faders and rotary encoders. IP-connected frame bays allow distributed placement for remote productions. Stage Tec’s new software release 4.5 adds audio processing highlights for Aurus and Crescendo desks. The company also announced at the show that it had joined the RAVENNA partnership.

STUDIO TECHNOLOGIES expanded its Dante-compatible offerings with three new compact, software-configurable announcer’s consoles—the Model 205, Model 206, and Model 208—that offer unique combinations of analog and digital audio resources to create on-air talent hubs for both AoIP and traditional analog audio environments.

WHEATSTONE debuted Screen-Builder 2.0, a new version of the development platform for its WheatNet-IP audio network that includes scripting tools and GUI for developing virtual news desks, producer workstations, control panels, and other virtual interfaces and workflows for the WheatNet-IP networked studio.

AUDIO RECORDING & PLAYOUT

AVID’S new Pro Tools|Ultimate includes the Avid Complete Plug-in Bundle and Pro Tools|MachineControl with cloud collaboration enhancements and Dolby Atmos mixing with supporting of up to 256 audio tracks. The Avid Connect App, available to Avid’s 1.4 million account holders this summer, offers a personalized connection into the Artist Community and Marketplace from computers, mobile devices and within Avid creative tools.

ZAXCOM is now shipping the fourth iteration of its Deva 24-track hard disc recorder, Deva 24 and Mix-16, a control surface for the unit featuring 16 motorized faders in five banks.

AUDIO MONITORING & METERING

RTW showcased its TM3 Smart and TM3-3G SmartTouchMonitors as well as TM7/TM9 TouchMonitors, MM3 MusicMeter and TM3-Primus. It also highlighted its software and plug-in solutions along with Nixer Pro Audio’s PD-Dante, a small portable monitoring and diagnostic system that is now available through RTW’s worldwide distribution.

TSL PRODUCTS unveiled the MPA1-MIXSDI, MPA1-SOLO-8 and MPA1-MIX-8, extending the range of connectivity to its MPA1 audio monitor line.

HEADPHONES/HEADSETS

AUDIO-TECHNICA announced the new BPHS2 broadcast stereo headset for news and sports broadcasting, available in the standard BPHS2 stereo and the BPHS2S single-ear versions, both with a hypercardioid dynamic mic, and the BPHS2C stereo with a condenser mic.

SENNHEISER launched its 300 PRO series, available in August 2018, comprising the HD 300 PRO and HD 300 PROtect monitoring headphones and HMD 300 PRO and single-sided HMD 301 PRO communications headsets.

AUDIO DISTRIBUTION, ROUTING & CODECS

AUDINATE released Dante firmware v4.1 for the Ultimo UXT family of audio networking chipsets, bringing AES67 networking to 2-and 4-channel count products. The company also launched Dante Domain Manager, which allows AV and IT professionals to define specific AV device groupings by room, building and site, allowing for the creation of independent Dante Domains and enabling a single Dante Domain to encompass multiple IP subnets.

ORBAN demonstrated OPTICLOUD Any Content | Any Device, a patented technology addressing the problem of voice intelligibility in the home as well as stereo/multichannel imaging for users who view content on mobile devices.

MICROPHONES

DPA MICROPHONES introduced its d:vote 4099 Instrument Mics with CORE, designed for use with every woodwind and acoustical instrument and featuring versatile mounting/clip options. DPA also unveiled CORE, a new amplifier technology designed to minimize distortion and increase the dynamic range of its d:screet, d:fine and d:vote lines of miniature lavalier, headset and instrument microphones.

SANKEN MICROPHONES’ new compact CS-M1 super cardioid shotgun microphone, for mounting on DSLR cameras, is intended for professional boom pole drama and film location recording applications.

SENNHEISER unveiled the Essential range of headset and lavalier microphones, available from July 2018, including the HSP Essential Omni omni-directional capsule and MKE Essential Omni omnidirectional lavalier microphone

WIRELESS

ALTEROS’ GTX Series L.A.W.N. ultra-wideband (UWB) 6.5 GHz wireless microphone system supports up to 24 channels via an antenna array (up to 32) and enables multiple systems to be used in close proximity with no interference and with no frequency coordination.

AUDIO-TECHNICA introduced its new ATW-T6002x handheld transmitter for the 6000 Series high density wireless system, plus a half-dozen new interchangeable microphone capsules.

PROFESSIONAL WIRELESS SYSTEMS announced the new PWS 4X4 quad antenna distribution for the Shure Axient Digital Quadversity wireless mic system. The new V-IC, 4-zone intercom multicoupler for the VHF range is intended for use with Radio Active Designs UV-1G wireless intercom systems. The new P-812S houses eight independent, passive two-way RF splitters, enabling two-zone transmission for up to four UV-1G base stations.

SENNHEISER’S new 500-p series professional packages for ENG and film work include the ew 512-p G4 Pro portable lavalier mic set, ew 500 BOOM G4 Pro portable boom set and ew 500 FILM G4 combo set variously ship with a camera receiver, bodypack transmitter, MKE 2 lavalier mic or plug-on transmitter and various accessories.

WISYCOM debuted its LFA ultra-wideband active antenna, which operates in the 410-1300 MHz frequency range and features three filters. The new BFA-B/BFA-N ultra-wideband booster can supplement existing antennas, ampliying the antenna signal up to +27 dB over the same frequency range.

INTERCOM & REMOTE CONTRIBUTION

CLEAR-COM’S new E-IPA IP card enables users to build out high density audio distribution and intercom systems by adding 16, 32, 48 or 64-port frame cards to existing Clear-Com Eclipse HX-Delta, Median, and Omega systems, and is AES67-compliant and SMPTE 2110-30-ready. Clear-Com also presented the BroaMan-brand of solutions including the MUX22-IVT/IC422, which integrates Clear-Com matrix-panel intercom connections including audio and control data transport.

COMREX unveiled EarShot, which delivers telephone-based IFB and live studio program audio to field-based remote broadcasts. Up to 30 users can listen to program or IFB feeds by calling into EarShot with a mobile phone. It can handle up to four program feeds or two IFB feeds, but for higher fidelity, smartphone apps can be used to pull the audio in studio quality.

EARTEC introduced the UltraLITE HUB series, which weighs 9 ounces and allows seven users to talk hands-free, in full duplex, simultaneous talk. Also new is Eartec’s UltraPAK, an ergonomic mini belt pack that allows the addition of lightweight headsets to the full duplex, simultaneous talk intercom.

GLENSOUND’S Beatrice R8 8-channel (expandable to 16) rackmount intercom system offers Dante/AES67 networking with 32 digital audio channels, two local analog I/O with two four-wire circuits plus redundant copper and fiber network interfaces.

RIEDEL COMMUNICATIONS introduced its new 1200 series SmartPanel, the RSP-1232HL, a 32-key user interface designed for workflow flexibility, power, and connectivity, including AES3 and SMPTE 2110-30 (AES67). Riedel’s new Bolero Standalone Application is a license-enabled upgrade that allows antennas to be daisy-chained to each other in a line or a redundant ring via a low-latency, synchronized TDM network, among other features.

RTS launched its Odin (OMNEO digital intercom matrix) IP comms system, scalable from 16 ports to 128, with the potential to gang up to eight panels to achieve 1,024 ports; it ships in June 2018.

STUDIO TECHNOLOGIES’ new Model 391 Dante Alerting Unit offers both visual and audible indications that attract operator attention and can be used in conjunction with Dante intercom beltpacks and user stations that support call light functionality.

TIELINE TECHNOLOGY unveiled a new 6-channel IFB and push-to-talk (PTT) intercom solution called ChatterBox. The ChatterBox smartphone app delivers up to six dedicated IFB and push-to-talk communications circuits over cellular networks (3G, 4G LTE, 5G) and Wi-Fi.

TELOS’ Infinity is a distributed IP intercom system based on VoIP and Livewire+ AES67 AoIP transports that integrates with existing analog, AES, SDI, and MADI systems using Telos Alliance xNode baseband-to-IP interfaces and other AES67 partner devices.

AUDIO PROCESSING

JÜNGER AUDIO launched AIXpressor, a 1RU x86 processor-based platform, equipped with a comprehensive range of built-in interfaces, supporting software-defined products that are created using Jünger’s new Flexible Audio Infrastructure flexAI.

NUGEN AUDIO showed the newly released Dolby E Module for the AMB Audio Management Batch Processor, offering improved processing speeds and greater scalability.

THE TELOS ALLIANCE announced a partnership with FiDef to deliver new audio-enhancing technology with a roundtable discussion featuring world-renowned producers, mixers and engineers Gary Katz, Al Schmitt, Frank Filipetti and Ed Cherney.

THX and QUALCOMM TECHNOLOGIES demonstrated an end-to-end THX Spatial Audio workflow using MPEG-H for the delivery of next-generation immersive audio experiences, including features to optimize audio playback over a wide range of consumer devices.

ACCESSORIES

BITTREE unveiled the limited edition 969A-Series 2x48 audio patchbay N96DC, featuring patented front-programmability and offering 96 TT (bantam) connections in a 2RU rackmount chassis.

This is the fourth installment in a series of articles about the newly-published SMPTE standard covering elementary media flows over managed IP networks. This month, the focus is on audio transport, specifically on uncompressed, studio quality audio for broadcast applications.

UNCOMPRESSED AUDIO

The full title of SMPTE ST 2110-21 is “Professional Media Over Managed IP Networks — PCM Digital Audio.” This standard is closely related to, and heavily based on AES67, which is titled “AES standard for audio applications of networks — High-performance streaming audio-over-IP interoperability.” Although the document titles may not be totally self-explanatory, both standards are all about transmitting raw, uncompressed samples of audio signals directly within RTP/UDP datagrams using an IP network.

To understand how audio signals are packed into these datagrams, it helps to remember that each individual channel of uncompressed digital audio signal is created using a fixed sampling frequency and a fixed number of bits per sample. In the case of ST 2110-30, all senders and receivers are required to support 48 kHz sampling, at a minimum. In broadcast applications, 24 bits (3 bytes) are generally used for every sample. So, for a 48 kHz, 24-bit stereo audio pair, the raw audio data would consume 48,000 x 3 x 2=288,000 bytes/sec which equals 2.304 Mbps without any packet headers.

PACKETIZATION

An example of how audio samples are placed into packets is shown in Figure 1, where an HD-SDI signal is separated into individual IP packet streams for each media type. Video is encapsulated using ST 2110-20 and ancillary data is done using 2110-40. Two audio groups are shown — one stereo pair and one set of 7.1 surround sound (which is eight channels uncompressed). Each of these signals is packetized into a separate stream, as shown in the two rows that make up the table. By keeping the number of audio channels at eight or below for each of the two packet streams, maximum flexibility in choosing receivers is achieved, since the minimum (Level A) conformance level for an ST 2110-30 receiver is eight channels.

[Read: What SMPTE-2110 Means for Broadcasters]

Four factors control the way that audio samples are packed into the RTP packets that make up a stream, and are listed in the table within Figure 1 for each audio stream. The four factors are:

· Audio sampling rate. Most broadcast applications today use 48 kHz sampling, so all ST 2110-30 senders and receivers are required to support it. Some applications use 96 kHz sampling, and 44.1 kHz can also be found in practice, so the standards recommends that both additional rates should be supported. Other sampling rates are out of scope for the standard.

· Audio sampling depth. Because IP packets are formatted in bytes, the audio data payload must be an integer number of bytes. Therefore, AES67 and ST 2110-30 only allow 16-bit and 24-bit audio sampling.

· Packet time. This parameter indicates the timespan covered by the audio samples contained in each packet. For example, when 48 kHz sampling is used with a packet time of 1 millisecond, there will be 48 audio samples from each audio channel in each packet. Note that longer packet times increase the end-to-end latency of the audio stream (because it takes longer to fill each packet) and shorter times increase the number of packets in a stream.

· Number of channels. Normally, all of the parts of a multichannel audio signal, such as stereo or surround sound, are transported in the same IP packet stream. Thus, a 5.1 surround sound signal would have samples from six different audio channels interleaved within each packet.

A receiver relies on information contained in the SDP (Session Description Protocol from RFC 4566) in order to properly interpret the packet contents. The SDP data, which typically consists of a few lines of text, can be transported in multiple ways from a sender to a receiver. SMPTE ST 2110-30 does not define a specific way to do this. Instead, methods are being developed by the AMWA (Advanced Media Workflow Association) for use by media production facilities.

Along with the four parameters described in the preceding paragraphs, the SDP values defined in ST 2110-30 provide standard order for the individual channels within the IP packets. Two examples of this are shown in the table in Figure 1, including both the symbols that are used in the SDP file (“ST” and “71”) and their associate channel order in the last column in the table. Symbols and channel orders are defined within ST 2110-30 for other audio systems such as matrix stereo, 5.1 surround and 22.2 surround (symbols “LtRt,” “51,” and “222,” respectively).

SMPTE ST 2110-30 also defines a set of six compliance levels for audio receivers, as shown in Figure 2. To achieve compliance at a particularly level, a receiver must be able to accept any quantity of audio channels in a single stream within the range shown in the table for each combination of packet time and sampling rate. Note that only the “–X” receivers are required to support 96 kHz sampling.

COMPATIBILITY & DIFFERENCES WITH AES67

One question that might be asked about AES67 and ST 2110-30 is: “Can they be made to work together?” The answer is: “Absolutely.” Because ST 2110-30 is based on AES67 and includes multiple “normative” (i.e. required) references, it is very easy to achieve interoperability. That being said, there are a few areas of difference.

First of all, ST 2110-30 receivers are not required to support SIP connection management for unicast audio signals. This is likely not an issue, since large audio networks frequently use IP multicasting to allow signals to be sent to multiple destinations simultaneously. This does mean, however, that ST 2110-30 receivers won’t be able to send or receive VoIP (Voice over IP) calls that use SIP for connection setup. Also note that RTCP (RTP Control Protocol) is recommended for use in AES67 but only needs to be “tolerated” in ST 2110-30 devices.

There are some differences with respect to how PTP (Precision Time Protocol, as defined in IEEE-1588) is implemented between the two standards. One important difference is that RTP clock offsets are not permitted in ST 2110-30. This means that AES67 receivers can work fine with ST 2110-30 senders, but that AES67 senders must not use an RTP clock offset when sending signals to ST 2110-30 receivers. There are also some differences in the specific profiles of PTP that are used in the two standards, however, the permitted ranges overlap so the two systems can be set up to work together.

One other slight difference: ST 2110 requires that every device has an option that allows it to be set in a PTP slave-only mode. When this mode is enabled, the device will never attempt to become a PTP master. This is important in large networks in order to prevent chaos when every device becomes available to take over as PTP master when an interruption in the PTP distribution system occurs. This option is not required in AES67, but should be a useful feature in many products.

HARMONIOUS SOUND

SMPTE ST 2110-30 was developed specifically to make audio as compatible as possible with video. By using the widely-accepted AES67 standard as a base, this new standard allows a wide range of existing audio equipment to harmonize with the rest of the 2110 suite.

Other entries in this series:

SMPTE ST 2110-21: Taming the Torrents

SMPTE ST 2110-20: Pass the Pixels, Please

SMPTE ST 2110-10: A Base to Build On

[Want more information like this? Subscribe to our newsletter and get it delivered right to your inbox.]

NEW YORK—Thanks to the adoption of the SMPTE ST 2110 standard, 2018 promises to be the year when integration of audio and video becomes easier and faster. The synchronization of all streams will simplify the process of recording content, pulling apart audio and video in order to work individually on the components and then bind them back together. How will console manufacturers respond to the new requirements?

Phil Owens, senior sales engineer, Wheatstone

AES67 will be the required audio format. Every packet in an AES67 stream is time-synched, making it possible to re-synch audio and video. Phil Owens, senior sales engineer at Wheatstone in New Bern, N.C., says that the new SMPTE standard will be good for his company.

“In the past, with HD-SDI, audio was embedded in the video stream,” he said. “You had to de-embed it—which required a bunch of hardware—then re-embed it, which required even more hardware. It’s going to take a while for stations to adopt AES67, but when they are looking at new systems they will have to make sure they support the SMPTE ST 2110 requirements.

“For us, it’s good because we have a whole IP infrastructure we’ve developed over the last decade, which has been used in a large number of radio and TV facilities,” Owens continued. “Our Wheatstone Blade network is an IP audio network that’s perfectly suited to supporting the SMPTE ST 2110 spec. If a station is looking at IP-based systems, the Blade offers great connectivity between various systems.”

Owens pointed to a second benefit to AES67 adoption. “All of the different platforms that are in use—house routers, audio systems, intercoms, for example, will now have a common protocol,” he said. “We’re constantly adding new features to the Blade network. The most recent is a utility that can be built in that will let a Blade connect to a Dante network. We’re continuing to develop control surfaces—what we used to call audio boards—that take advantage of our Blade network and use it as their backbone.”

MOVING AWAY FROM THE PHYSICAL
Logitek Electronic Systems is banking on a continued migration away from physical consoles, according to Frank Grundstein, director of sales for the Houston-based company. “The world has become accustomed to touchscreens,” he said. “Whether they are in a mobile phone, on a tablet or part of an automation system, touch devices are now the norm for running applications and making menu choices. Consequently, in the audio world for local market television, we have increasingly seen a move away from large mixing consoles.”

Stations that rely heavily on automation tend to prefer having no physical audio console at all, according to Grundstein. “A ‘virtual’ console presented on a touchscreen supplies all the controls needed for local takeover of audio. Most control is handled via the program automation system,” he said. “While some users still prefer the convenience of a physical board, they don’t need or want an audio console that takes up half a room.”

To address these changing needs, Logitek introduced their Helix line of consoles in 2017.

The Helix line incorporates a “glass cockpit” approach to audio management as well as commonly requested physical components. Two models for television production are available: Helix Studio, a full-featured touchscreen console with multitouch capability; and Helix TV, a physical board with a mix of touch-sensitive automated faders and touchscreens for source selection, metering and other functions.

The physical console, available in configurations ranging from 6–36 faders, is compact yet provides all the audio control needed for local market TV operations. As a virtual device, Helix Studio can be configured to meet any station’s requirement for faders, source selection, monitoring, metering and more. Both products work in tandem with the Logitek JetStream Plus AoIP router, which addresses another TV market need—minimal rack space requirements—with 240 channels of I/O in only four rack units.

The cost of a system is based on the number of faders and how much audio I/O will be needed for the router, according to Grundstein.

“Most TV facilities have been buying a physical console with 24 faders,” he said. “They sometimes go up to 36 but generally don’t need that many faders. Some station groups have determined that they don’t want any physical control surfaces in their studios.”

Some operators are not comfortable working without physical faders, Grundstein added. “They may buy a physical console, but because the consoles are router-based, they buy one that has fewer faders than the ones on the board they’re replacing,” he said. “Other engineers feel that everything is going into automation and simply do not need any physical faders. Our virtual console, the Helix Studio, connects to the JetStream engine. When the automation system tells the audio engine to do something the moves reflect on the displayed fader.”

Dave Letson, vice president of sales, Calrec

REMOTE POSSIBILITIES
U.K.-based audio console developer Calrec is targeting remote broadcasting. “Traditional broadcasters are seeing huge competition from on-demand web streaming services,” said Dave Letson, vice president of sales. “To counter this, they are looking to cover more live events, and some are moving into niche programming to provide a broader choice and a more tailored viewing experience. To achieve this more versatility is being demanded from the audio console.”

Calrec’s Apollo console is a natural fit for this market, according to Ian Cookson, communications manager. “The real benefit of remote production is not really size reduction but the exact opposite,” he said. “It allows the broadcaster to do more with their resources for a nominal expenditure when compared to using traditional methods.”

For example, an Apollo console based at a sports broadcaster’s HQ can now cover multiple games from multiple locations, allowing providers to offer less popular sports that may not pull the viewing figures to warrant the expenditure of a full OB truck, Cookson noted. “As viewers are changing the ways they consume TV, there is an expectation to be able to watch whatever they desire,” he said. “Broadcasters need to keep up with this demand but don’t necessarily have the budget to use traditional methods. This way the output increases and the quality doesn’t suffer.”

Calrec addresses this need for remotely controlled audio with the RP1, which is essentially a mixing console in a 2U box, according to Cookson. The RP1 allows the broadcaster to overcome the three main hurdles for audio in a remote production workflow: latency, control and transport.

“The RP1 has DSP inside so it can mix locally at the venue so this will eradicate any latency for monitoring and IFBs,” he said. “These DSP resources are controlled from the main console at the centralized facility.”

This control data is a really small amount of information so the delay from the fader on the surface to the DSP in the RP1 is nominal. Plus the RP1 integrates with any of the backhaul technologies broadcasters use, from a traditional embedded SDI stream to emerging AoIP technologies.

“Calrec has an AoIP solution—a 1RU rackmount box that connects to Calrec’s consoles via the proprietary Hydra2 protocol like any other IO box,” Cookson said. “This acts as a gateway from Hydra2 to AoIP using the AES67 standard.”

These boxes can accommodate 1 or 2 cards, giving either 256 or 512 bidirectional signals, which is one of the highest density AoIP solutions currently available, according to Cookson.

“To the Calrec user the AoIP ports appear on the console like any other IO box and so there is no learning curve and sources can be patched to and from the AoIP box quickly and easily.”

Over the last 15 to 20 years, broadcast audio systems have undergone revolutionary changes—from analog to digital technologies, from manual to computer-assisted workflows, integrating related systems such as telephones and intercom systems, and much more.

One key enabling technology is Audio over IP (AoIP), which delivers a number of significant benefits, including operational flexibility, scalability and lower costs. However, implementing AoIP systems to take advantage of these benefits depends almost entirely on the existence of and support for interface and interoperability standards to ensure that the many elements that make up professional audio systems are capable of working together. To that end, there are several AoIP protocols designed to achieve this goal by easing implementation and integration, including the increasingly popular Livewire+ AES67.

Originally known as Livewire, this pioneering technology was created in 2003 by the Telos Alliance as a means of transmitting low-latency, high-reliability audio over switched Ethernet. Livewire+ AES67 adds full compliance with the AES67-2013 interoperability standard for high-performance AoIP transport over IP audio networking products. This allows devices to seamlessly connect directly to Livewire+ networks for connecting audio streams, regardless of device type or manufacturer. Livewire+ AES67 also offers the flexibility to incorporate and comply with future AES and SMPTE standards as they are approved and released, while simultaneously offering backward compatibility with the RAVENNA networking protocol.

Today, 70,000 connected devices worldwide use the Livewire or Livewire+ AES67 protocols, and 100 companies provide compatible equipment. While these numbers are impressive, adoption continues to grow steadily for a number of key reasons.

EASE OF INSTALLATION AND USE

In the coming years, studios’ transition to IP will continue, but the number of available protocols, methods, hardware and audio devices can make the process confusing. Livewire+ AES67 cuts through this noise to accomplish interconnectivity more easily at a lower cost.

Using Livewire+ AES67, uncompressed digital audio, device control messages, program-associated data and routine network traffic is carried over a single Ethernet cable in real time. This reduces the number of cables to deploy, significantly reducing the time required to wire an entire facility. All sources and devices connect using readily available Ethernet cables, which can carry up to 250 audio channels each, depending on the network link capacity. This link aggregation eliminates expensive multi-pair cable for interconnecting studios, resulting in potentially significant savings in labor costs alone.

Configuration can also be just as simple. With Livewire+ AES67, every audio source is given a text name and numeric ID, which are transmitted from devices over the network thanks to a built-in device discovery mechanism. All hardware products have built-in web engines that can be accessed via any common browser or by using an Axia program called iProbe. Users simply enter the names of their desired input sources using just a PC and web browser, with a configuration window enabling any necessary parameter changes for the selected sources.

As a result of these capabilities, installation and configuration, which may have taken weeks in the past, can now be completed in hours thanks to Livewire+ AES67.

AUDIO QUALITY AND RELIABILITY

Unlike Internet audio, which suffers from reduced quality as a result of limited and variable bandwidth, Livewire+ AES67 uses Internet protocols but is intended to deliver uncompressed audio over local area networks (LANs). Livewire+ AES67 is the only fully compliant protocol that also features Unicast SIP modes of operation, meaning it is also suitable for VLAN and WAN applications.

The controlled, high-speed Livewire+ AES67 network provides more than adequate bandwidth for large numbers of channels of high-quality uncompressed audio in real time, eliminating the risk of audio drop-outs from network outages and other issues affecting transmission. Long accepted as a reliable means of transporting virtually any kind of data or signal, IP has become a reliable option for telephone, intercom, teleconferencing and many other applications. According to the Telos Alliance, as of April 2015, more than 5,500 studios around the world had been built using the company’s Axia IP-audio infrastructure employing the Livewire+ AES67 protocol for mission-critical broadcast applications in major metropolitan markets.

COST SAVINGS

A key benefit of Livewire+ AES67 is its ability to enable computer data, phone, audio and control to be transmitted on a single network. Naturally, this type of converged networking environment can generate significant cost-efficiencies throughout a broadcast facility.

Further contributing to the cost-effectiveness of Livewire+ AES67 is that the most widely used and highly respected companies in the radio industry have adopted the technology. This allows broadcasters to select best-of-breed solutions and connect as many audio devices as possible directly to their audio network. In addition to simplicity, this removes the need for extra I/O devices, delivering even lower overall system costs.

Livewire+ AES67 allows wiring to be installed in hours, as opposed to the weeks that are often required. Livewire+ also generates savings from the way it handles audio from PCs, which nearly all broadcast stations use as their primary means of playing and editing audio. With a traditional network, PC-based audio is transmitted through a router input card or console module, which adds significant cost when bringing multiple audio channels into the system.

The latest release of Livewire+ AES67 includes a driver that can handle up to 24 bi-directional stereo or mono audio streams directly through a computer’s network card and now features PTP clock synchronization. This allows the computer to be connected directly to the network using an existing Ethernet connection, eliminating the cost of an additional sound card and the port needed to connect it to a console or router. In many cases, this can save broadcasters many thousands of dollars.

Studios’ transition to IP-based broadcasting has been underway for several years, but has been hindered by the sheer number of protocols, integration methods, legacy hardware and advanced audio devices, which can be confusing at best. The advanced capabilities and other key benefits of Livewire+ AES67, on the other hand, simplifies interconnectivity and upgrades, while offering greater flexibility and cost-effectiveness.

By implementing Livewire+ AES67 solutions, studios can take advantage of best-of-breed technologies to satisfy a wider range of applications within network environments. Best of all, Livewire+ AES67 is designed to work with future standards as they are released. This ensures that the Livewire+ AES67 will never be obsolete and continue to deliver quality, reliability, flexibility, cost savings and many more benefits well into the future.

John Schur is the president of Telos Alliance TV Solutions Group.

LOS ANGELES—As computer scientist Andrew S. Tanenbaum noted, somewhat tongue in cheek, in his 1988 book “Computer Networks,” “The nice thing about standards is that you have so many to choose from.”

The computer industry has long since become a multivendor business, enabling consumers to pick and choose components from a variety of brands, safe in the knowledge that they work together. That paradigm will become increasingly valuable to broadcasters, too, as digital audio—and video—networks are increasingly adopted.

STANDARDIZATION
Bringing standardization to digital audio networking, the Audio Engineering Society published AES67, which enabled high-performance streaming audio-over-IP interoperability, in September 2013. After three years, are we anywhere nearer to that multivendor paradigm?

Kevin Gross

“There are a lot of implementations out there,” said Kevin Gross, an independent consultant who led the group that developed and ratified the AES67 standard. For example, he said, Audinate Dante devices now offer AES67 support and QSC very recently announced that its Q-Sys platform will support the standard.

Indeed, the universe of AES67-compliant products has expanded to include equipment from the likes of Wheatstone, Calrec Audio, Lawo, Yamaha and others. Perhaps more importantly for the broadcast industry, video equipment manufacturers are implementing AES67 for audio transport. And within the broadcast video industry, certain standards have been developed that adopt AES67 to handle digital audio, he said, including the Video Services Forum’s TR-03.

SMPTE 2110 intends to codify TR-03 (therefore AES67) and TR-04 audio and video IP transports within that standards body. Standing behind TR-03 is the Alliance for IP Media Solutions (AIMS), a nonprofit alliance promoting the open standards that enable the industry to move from legacy SDI systems to IP-based transports.

“AIMS has done public interoperability demonstrations; there was a big public demonstration of TR-03 technology at IBC,” said Gross. “If you look carefully, the AES was part of that demonstration, as was the Media Networking Alliance, supporting AES67. Any of the audio in those demonstrations was AES67.” There will be another demonstration building upon those previous events at [the 2017 NAB Show], he said.

AES67-2013 was subsequently revised as AES67-2015. “We just clarified some things,” said Gross. “I hope we’ll be able to revise it again in 2017.” He reported that the Task Group is currently developing PICS, (Protocol Implementation Performance Statement). “It’s a big matrix that spells out what pieces of the standard are implemented. This is a mechanism that allows somebody to communicate what options they have included in their implementation.”

The statement will also provide guidelines for testing. “We don’t have a compliance program like the AVnu Alliance does for AVB. Testing must be done by the individual manufacturers, so this will be helpful in improving the quality of implementations,” said Gross. AES published a report in May 2016 on interoperability between AES67, SMPTE 2059-2 and IEEE Std 1588-2008 using Precision Timing Protocol (PTP). “They’re compatible,” said Gross, “so we expect everybody to be able to use a single synchronization system for their audio and video. SMPTE has been doing some interoperability testing that is ongoing.”

PLUGFEST TESTS
The AES has also conducted plugfests between components from different manufacturers. The first was in Munich in 2014, followed by another in Washington, D.C., in 2015. A third will take place at the BBC this month, said Gross, and a report should be published in March that will list the manufacturers, which is expected to include video equipment companies with early implementations of SMPTE 2110, he added.

Jeff Berryman

AES67 describes how audio flows over networks. A related standard, AES70, is about controlling audio devices remotely over networks. “AES67 does not completely specify a standard connection management method, so different manufacturers have started using different methods with the result that, although these devices can potentially exchange audio, they sometimes have trouble doing so because they don’t speak the same language as far as establishing the connection,” commented Jeff Berryman, senior scientist at Bosch Communications.

AES70, the standardized version of Open Control Architecture (OCA), was published in 2015. Berryman chairs the SC-02-12-L Task Group on AES-X210, which was the original project that ratified OCA. “X210 is about to start working on a document to describe how you use AES70 to manage the connections of AES67 networks. It will be an implementation guide,” he said.

The AES67 standard did not mandate discovery or control functions. AES70 rectifies that, providing standardized control management that helps connected devices to establish, and later break, connections and direct the flow of audio around the network. “AES70 can potentially work with a wide variety of media transport protocols, not just AES67,” said Berryman.

AES70 uptake is somewhat slower than for AES67, he reported. “The control problem is a little bit secondary in people’s minds, so AES70 hasn’t had the explosive growth that AES67 has, but it’s coming along steadily.” He expects the connection management aspects of AES70 to be revised this year in a third iteration, to be known as CM3.

The scheme has been championed by the OCA Alliance for a couple of years. “We’re starting to have companies now that are not members of the OCA Alliance doing OCA implementations, which is encouraging,” said Berryman. “We don’t want everybody to feel that they have to join the OCA Alliance to implement AES70; that’s not the point.”

There is an alternative connection management scheme developed by the BBC known as Network Media Open Solution (NMOS) that is supported by Advanced Media Workflow Association (AMWA) in collaboration with AIMS, Berryman noted. “NMOS is far more visible in broadcast than anywhere else. Ravenna—an AES67 implementation—has a version that uses NMOS for connection management.”

Berryman stressed, “AES70 has been designed from the outset to coexist with other connection management solutions. Yes, there will be two standards; and the ability to coexist, which is relatively routine, will be defined by AES70. AES70 has a good way of making devices bilingual.”

Logitek Talks AoIP

TV Technology recently talked with Logitek President Tag Borland about AES67 and athome production capabilities.

TV TECHNOLOGY:How has AES67 affected the design of your current products and how Logitek designs future products?
TAG BORLAND: The AES67 protocol is being designed into all our new products. To fill in the gaps we are in the process of implementing the discovery sections of NMOS.

TVT:Does Logitek participate in the AES67 interoperability “plugfests” to ensure integration with other brands?
TB: We currently do in-house testing against a selection of products from other vendors.

TVT:Will Logitek implement AES70 to offer their users tighter integration with other products?
TB: We already fully support the control interfaces for many switcher and automation systems via IP. Logitek will continue to provide protocols as needed but the complexity of AES70 compared to its perceived benefits may slow adoption.

TVT:Do any of Logitek’s products offer “athome production” capabilities?
TB: Logitek provides an IP-based glass console control system with each Jetstream mix engine. This product allows an operator to use the same features and functions remotely as they can from the hardware control surface. It is also possible to combine faders and control from multiple mixers at multiple sites into a single on-screen experience. The vMix+ design tool allows users to customize default screens for maximum efficiency or to create whole new ones to their own requirements.

MUNICH—Class was in session for those in attendance at the Genelec Experience Centre in London, as Ravenna and Genelec teamed up to host an educational event of AES67.

“Everything You Wanted to Know About AES67 But Were Afraid to Ask” began with an introduction from Roland Hemming of RH Consulting, who provided an overview of audio networking, adoption levels across the industry, and examples of projects that rely on audio networking. Then ALC NetworX’s Andreas Hildebrand led the class by explaining the specifics of AES67, how it works and how it impacts the industry’s increasingly connected environment.

After that, Hildebrand offered a live demo of an AES67 system using a Cymatic Audio uTrack24 multitrack recorder/player, an ARG switch, a Grandmaster clock from Sonifex, a Ravenna Virtual soundcard, and Genelec 8430 IP speakers. Later, a Dante device was added to the setup to show streams running back and forth between the Ravenna and Dante eco system.

Hildebrand said after the event that it is likely that Ravenna will host similar events in the future, though no details are available at this time.

It should be apparent by now that future broadcast and media infrastructure will be IP-based. The advantages include simpler cabling, remote device management, easier interconnection, increased channel count per-connection, and the prospect of utilizing existing network infrastructure to minimize cable costs. The hands-on experience I’ve had with audio-over-IP equipment to date has been incredibly positive and the occasional issues experienced when interconnecting devices that use different protocols is being sorted out quickly thanks to solidifying industry standards.

As optimistic as I am about the technology and the positive results it will yield, there is an underlying issue with moving everything to the network that no one is talking about—the relationship between the information technology and broadcast engineering departments. It appears that the technology portion of this transition has been maturing nicely while the collaboration piece is still a bit rocky.

The foundation of a new networkYOU WANT IT FAST OR RELIABLE?
An IT department provides networking, desktop support, and most importantly, security to our businesses—not to serve broadcast—and the scale of the IT industry dwarfs ours. One benefit of being so massive means that IT equipment is less expensive and more widely available than traditional broadcast gear so our industry has gravitated toward it as a way to cut costs and capitalize on existing technology, leading to crossover and conflict. IT managers understand the needs of the business in ways broadcast engineers likely never will but they have trouble wrapping their heads around the immediacy and urgency of the television and media worlds. Where IT has very structured processes, broadcast was built on and often still operates by the seat of its pants. These differing methodologies have given rise to a question that is not easy to answer: Should television engineers become IT engineers? The answer is, as usual, “It depends.” End users simply connecting equipment and using it for production are probably fine continuing on their merry way, however, support engineers would be well-served to develop their skills in IT protocols, networking, hardware, and security.

Supporting just a handful of the protocols used in the AES67 interoperability standard for audio-over-IP would require engineers to have some understanding of Internet Group Management Protocol (IGMP), Internet Protocol (IP), Precision Time Protocol (PTP), Real-Time Transport Protocol (RTP), Session Description Protocol (SDP), Session Initiation Protocol (SIP), and User Datagram Protocol (UDP). This collection of standard IT protocols is used to initiate, describe, and deliver packets of audio over a network with minimum latency, but knowing the function of each is helpful for troubleshooting audio-over-IP transport issues, just as understanding circuits and signal flow helps an engineer diagnose issues when equipment fails.

ALL OR NOTHING?
Networking is more than just the parts and pieces used to glue things together; it also includes deciding where equipment will live on the network and how devices will interact with each other and users. Among the most immediate questions are whether broadcast equipment will reside on the business network or on a separate media network, and whether it will need access to the outside world, or simply reside on a closed, purpose-built network. Keep in mind that as a network’s complexity increases, so does the knowledge required to build and maintain it, and the level of security necessary to protect it. My experience to this point is that IT wants control of everything that touches the business network, so broadcast ends up creating a separate network, totally eliminating the advantage of using the existing IT infrastructure. Building a separate network requires not just the installation of more cable and connectors, but additional switches, routers, and firewalls. However, the additional equipment costs are generally offset by the time saved not waiting on decisions and responses from IT, with engineering taking over as the de facto local administrators that are already primed to respond to the needs of the broadcast environment.

Security of the network and the devices residing on it is the most critical area and the trickiest to get right. Implementing hardware firewalls (aka Adaptive Security Appliances or ASA), closing open ports, and installing antivirus and anti-malware software are absolute minimum security measures for every network. Care needs to be taken that any security software running on production machines does not interfere with or bog down the systems. Some antivirus suites are notorious resource hogs so everything should be thoroughly tested prior to full rollout. Full-time and temporary remote IP connections for interviews or content contribution are part of daily broadcast operations that open networks to the outside world so the connection path should be planned carefully and only necessary ports should be allowed access. External IP addresses that redirect through the internal firewall, private virtual local area networks (PVLAN), and VLAN Access Control Lists (VACL) are tools that give access to the internal network while keeping it secure and, though they are complicated to configure, tend to provide consistently reliable connections.

Fortunately, there are already people working in broadcast who understand the world of IT but have found satisfaction working in broadcasting, despite the chaos and odd schedules. For the rest of us, there is a learning curve ahead, even if we aren’t seeking certifications or in-depth IT knowledge. The world of IP for media and television is here and broadcast engineers of all disciplines need to improve their IT skills to stay relevant. Whether improving IT skillsets leads to CCNA or CompTIA certifications will depend on the desire of the engineer and the needs of the business, but it certainly won’t hurt the broadcast or IT departments to have more skilled people around.

Jay Yeary is a broadcast engineer and consultant who specializes in audio. He is an AES Fellow and a member of SBE and SMPTE. He can be contacted through TV Technology magazine or attransientaudiolabs.com.

MUNICH & TORONTO—Ward-Beck Systems, a Toronto-based provider of broadcast equipment, has announced that it has added Ravenna/AES67 connectivity to some of its products. Among the company’s set of products that now come with Ravenna/AES67 connectivity include the AMS2-N two-channel monitor, AMS8-N eight channel monitor, 32ME-N dual 16 channel network converter with metering, and MLC8-N eight channel converter with metering and level control.

Ravenna is a technology for real-time distribution of audio and other media content in an IP-based network. The Ravenna technology was developed by Munich-based R&D company ALC NetworX.

Ward-Beck joins a group of other companies that are part of what ALC NetworX calls the Ravenna community. Other members include 2wcom, Calrec, GatesAir, Lawo, Linear Acoustic, Riedel, Sennheiser and more.

As AES67-compliant products continue to come on the market, how can we be sure they are really compatible with each other with no test equipment currently available to verify compliance?

One way is to hold a “plugfest” where manufacturers of products that incorporate AES67 can get together, hook up their products to each other and see what happens. Such a plugfest was indeed held at the beginning of November 2015 at National Public Radio headquarters in Washington, D.C. This followed up on a previous plugfest held in Munich, Germany in 2014.

“The idea of the plugfest is to be able to perform testing in a true engineering environment where ideas can be freely exchanged,” said Phil Owens, senior sales engineer, Wheatstone Corp.

Held under the aegis of the Audio Engineering Society, the plugfest was organized with the goal of checking the extent of interoperability of the 13 separate products brought in for testing. The manufacturers that participated were ALC NetworX, Archwave Technologies, Digigram, DirectOut, Lawo, Meinberg Radio Clocks, Merging Technologies, Telos Corp., Wheatstone Corp., and Yamaha Corp.

GETTING DOWN TO BUSINESS
Over the course of the plugfest a series of tests were conducted. The first test checked the ability of the devices to be synchronized to a central grandmaster clock configured for Precision Time Protocol (PTP) as defined by IEEE-1588. Actually two ports of the clock were used, each set to a different PTP domain. One of the grandmaster clock ports was set to PTP domain 0, which is the IEEE-1588 default profile; and the other for PTP domain 1, which is the media profile according to AES67, Annex A. AES67 recommends using this profile, but doesn’t mandate it.

Each clock port was connected to a different Ethernet switch, each from a different manufacturer. Then those two switches were connected together so that each PTP domain was available on both switches. In the course of testing, the various devices under test were hooked up to each of the master switches.

The next test checked multicast streaming with multiple devices transmitting streams and multiple devices in turn receiving the streams. A standard stream was used for all tests with its parameters described in Session Description Protocol (SDP).

The third test checked unicast streaming with Session Initiation Protocol (SIP). There are three SIP modes—receive only, send-only and send/receive, that were all tested.

There was also a test checking on the network itself and media clock recovery.

From left: Johan Boqvist (Swedish Radio) in discussion with Greg Shay (Telos Alliance) and Sonja Langhans (IRT). Image courtesy of AES.THE RESULTS?
How did everyone do? Pretty well, actually, although some issues were discovered. In the spirit of open discussion and discovery, the results of the tests did not identify the names of the products, which were indicated only by random letter designations.

“There are benefits for the process to have anonymity,” said Greg Shay, chief science officer, Telos Alliance. “Otherwise vendors might be hesitant to participate.”

The good news was that most of the devices were able to synchronize with the grandmaster clock in either PTP domain. One device didn’t work with one of the switches, but worked with a different non-PTP switch. And another device didn’t work with the PTP domain 1.

In the multicast streaming test, most of the devices successfully interoperated with each other, although there were some issues related to SDP. Some receivers were more sensitive than others in interpreting SDP packets. In other cases, non-compliant SDP packets were produced, which prohibited the streams from being received. Some devices could read SDP automatically, others manually. AES67 doesn’t specify how SDP data is transferred for multicast sessions.

For the unicast streaming test, most devices were interoperable in one mode or another, but there were issues with SIP. In only one caller-callee combination of devices, all three SIP modes worked. But it was more common that only the receive-only mode worked, where the caller receives the audio stream.

There were some combos where receive-only and send-only (where the caller sets up the path, but the callee receives the audio) operated correctly, and a couple of combos where only the send/receive mode (bidirectional streaming where both caller and callee are sender and receiver) operated correctly.

“We learned that there is a good level of basic connectivity between all the participants’ equipment,” Owens said. “Overall the results were promising and bode well for the continued development of AES67. Further work on SIP was identified as a good next step in refining the protocol.”

Even with the SIP issues discovered, Shay said, “implementation of session initiation protocol was less of a hurdle than some people expected.”

Besides testing interoperability among the various devices, the plugfest showed that the standard itself was well-written and unambiguous.

“The fact that the success rate was very high was taken to mean that the heart of the standard is complete, well thought-out and explained enough,” Shay said.

Another factor to the interoperability success is attributed to AES67, which—although it is a new standard—is based on technologies that have been in existence for 15–20 years, and is used in telecommunications and other fields. This made it easier to understand and implement for pro audio applications, according to Shay.

A pleasant surprise that came out of the plugfest was that one of the vendors wrote a utility tool for doing third-party translations of different methods of discovery.

“In Appendix E of AES67, there are four different methods of discovery listed, and the standard didn’t mandate the use of any one. To choose one would be limiting,” Shay said. “There is room for innovation in solving the discovery problem, and we knew it would get solved in time.” That someone brought in such a tool to help the discovery process was an example of the innovation that could be possible.

Shay said there were expectations as well as hope that manufacturers of pro audio test equipment would add an AES67 test option to their gear to aid in checking compliance.

The number of manufacturers participating in the most recent plugfest indicated to Shay that there is “wind in the sails” in implementing AES67.

“You wonder when a new standard comes out: ‘Will companies commit their resources, do their own development and make this work?’” Shay said. “We see people are leaning into this and we got a good cross-section of vendors. Without a doubt, AES67 has critical mass now. All of the vendors of proprietary audio-over-IP are on board actually delivering first workable implementations, and with this [past] fall’s AES convention and the plugfest, we feel that AES67 is over the hump and is embraced for real by all the vendors.”

Mary C. Gruszka is a systems design engineer, project manager, consultant and writer based in the New York metro are

LOS ANGELES—The ability to pass audio over IP between different brands of mixing consoles and other equipment potentially became somewhat easier with the publication of the AES67 standard in late 2013. AES67 may not be as comprehensively functional as other currently available audio networking protocols. Nevertheless, it offers a standardized method by which equipment can share signals, alongside those other networking protocols as well as transports such as AES3 and AES10, otherwise known as MADI.

Television broadcast appeared to reach something of a tipping point in 2015 with regard to the acceptance and adoption of IP-based audio and video workflows and infrastructures. But the industry’s wider AoIP adoption has lagged slightly behind other sectors such as live sound and radio broadcast, where audio networking has been in use for quite some time via various protocols, including AVB, CobraNet, Dante, EtherSound, Livewire, RAVENNA, WheatNet-IP and others.

INTEROPERABILITY TRANSPORT STANDARD
AES67 was not developed to supplant existing AoIP networking platforms; indeed, it lacks certain features found in other AoIP protocols, such as a specified method for channel or device discovery, signal routing and labelling, and system control. But AES67 is essentially a subset of RAVENNA and is supported by Dante and other audio networking protocols, enabling broadcast consoles of various brands to interoperate with a very wide variety of IP-enabled products and, potentially, with each other.

SSL’s System T broadcast audio production system environment, incorporates networked audio, control, and processing based around Dante networking technology. Paul MacDonald, spokesman for U.K.-based Solid State Logic, a Dante licensee, said “AES67 is an interoperability transport standard—control and discovery are intentionally not defined—and as such we don’t view it as a competing technology to Dante, but a complementary standard. However, we think there are developing standards, within the AES and beyond, that have the potential to provide future extensions to standards-based interoperability alongside AES67.”

SSL’s latest broadcast audio production environment, System T, incorporates networked audio, control, and processing based around Dante networking technology, according to MacDonald. “Dante is by far the most widely adopted and, we believe, the most complete and practical audio networking solution,” he said.

Wheatstone, whose Series Four, Dimension Three and other IP consoles route and control audio through the company’s proprietary WheatNet-IP Gigabit Ethernet network, values AES67 for its ability to bridge between its network and others. Phil Owens, head of Eastern U.S. Sales for the New Bern, N.C.-based company noted that AES67 “provides the common synchronization, clock identification and session description we can all share in order to transport audio between our various systems without jitter, delay and data dropout.”

Wheatstone was one of the first to add AES67 to its WheatNet-IP system as another way to “get in and out of our system,” alongside analog, AES, MADI and HD-SDI, Owens said, adding that AES67 is complimentary to WheatNet-IP’s full system approach.

A European plugfest held in October 2014—the first for AES67—led to revisions in the standard, published as AES67-2015, that included some minor updates. At the 2015 AES Convention in New York the Media Networking Alliance (MNA), founded by a group of manufacturers to promote awareness and uptake of AES67, held its first public display of audio networking using the interoperability standard. That demonstration included 22 products from 18 different companies.

Wheatstone products interconnect through the company’s proprietary WheatNet-IP Gigabit Ethernet network. Wheatstone Engineers Kelly Parker and Dave Breithaupt participated in the second AES67 plugfest, held recently in Washington, D.C., and reported on the event on the company’s website. AES67 requires support for both unicast and multicast streaming, the latter requiring SIP, the Session Initiation Protocol that is also behind Voice-over- IP (VoIP) communications, for connection management. According to the report, WheatNet-IP supports SIP, but SIP interoperability was not achieved by every product at the plugfest. It notes that a subsequent AES report “suggests that an SIP technical overview and recommendation be published prior to subsequent AES67 plugfests.” The next plugfest is currently planned for the U.K. during 2016.

Calrec, which has been refining its Hydra2 networking scheme for the past 15 years, is the only broadcast console manufacturer to support all current protocols, including RAVENNA, AVB, Dante, and AES67, according to Dave Letson, vice president of sales for the U.K.-based company. Hydra2 provides a layer of management over all those signals, he noted, providing a multitude of additional functionality like port protection, alias files, virtual patchbays, and access rights. “Uniquely, Hydra2 provides the ability to apply the same management functionality to any supported protocol, providing control and functionality irrespective of which protocol our customers choose for their facility,” Letson said.

A NEW ALLIANCE
An AES standards project, designated X210, is currently addressing an interoperable control protocol. Open Control Architecture (OCA), a technical descendent of AES24, first published in 1999, appears to be on track for ratification as a control and monitoring standard providing interoperability across audio—and, eventually, video— transports. A group of manufacturers has formed the OCA Alliance to actively promote the adoption and standardization of the architecture.

“The lack of an accepted standard is frustrating for both broadcasters and manufacturers alike, and so the main value of these alliances is to provide information and support so that we can all make informed choices for the future,” said Letson. “We are all coalescing protocols into a unified standard and there is still some cautiousness amongst broadcasters and manufacturers in committing to a single standard.”

Lawo has always been aligned to open standards, be it SMPTE 2022-6/-7 and TR-03 in video, AES3, MADI, RAVENNA, or AES67 in audio, or Ember+ in control, according to Andreas Hilmer, director marketing and communications with the German-based company. “We strongly believe in these standardized, open approaches in order to come to best possible solutions with a solid and secure long-term perspective for our clients,” said.

Lawo recently announced that it had joined AIMS, the Alliance for IP Media Solutions, “an independent trade association founded to ensure that all IP solutions brought to market offer complete interoperability and are based on open standards for seamless integration into media workflow environments,” according to an AIMS statement.

“AIMS’s support of open standards and technical recommendations such as TR-03, TR-04, and AES67 afford us an opportunity to eliminate the fragmentation of implementations that our industry has endured over the last 20 years. It’s our big chance to avoid repeating expensive and time-consuming mistakes of the past,” said Hilmer. “In order to support the transition to IP-based infrastructures, we encourage all manufacturers to come together and embrace interoperability and open standards as the best solution for our mutual customers.”

Immersive audio took off in a huge way in 2014, especially in cinema with the release of films in Dolby Atmos and Auro 11.1 formats. The Traumpalast in Backnang, Germany was one of the first theaters to install a Dolby Atmos system, which includes a total of 57 speakers.

Here we are at the beginning of 2015, and as with all new years it is fashionable to analyze how the previous year went and take a look at how this new one might unfold. In this column dated Jan. 1, 2014, I made some predictions about what I thought the big stories of the year would be in the world of television audio. So let’s assess my prognostication skills and see whether they’ll hold up this year.

# 1: REFINEMENT OF THE CALM ACT—INCORRECT
My first prediction of last year was that the CALM Act would be further refined to make it easier to understand and implement, and this simply did not happen. There was almost no movement around the CALM Act this year other than the FCC finally adopting the 2013 revision, and the ATSC winning a well-deserved Primetime Emmy for A/85.

The rest of the year turned out rather quiet on the loudness front (pun definitely intended), with consumer complaints tapering off from an initial surge. Whether this is due to consumers actually being satisfied with the results of CALM implementation— or because they’ve given up reporting because they see no public vilifying of broadcasters over loud commercials—is something we don’t yet know; but most broadcasters seem to be doing a good job of keeping loudness under control.

It will be interesting to see what happens as initial two-year waivers expire; whether the FCC will allow extensions to those waivers due to the adoption of A/85:2013; and whether there will be any significant enforcement of the CALM Act. I think we’ll see some minor news regarding CALM this year, but it is unlikely to be anything significant.

# 2: AUDIO OBJECTS, NOT IMMERSIVE AUDIO—INCORRECT
It may not have been possible to be more wrong about this prediction than I was, and it’s partially the result of attending events where discussions take place regarding technology that remains years away.

Since audio objects for broadcast are tied directly to the rollout of ATSC 3.0, and since we won’t see a candidate standard for it until 2016, audio objects for broadcast are a technology of our future rather than our present. The work on this is so current that it was just a month ago (Dec. 5, to be exact), that the ATSC issued a Call for Proposals for ATSC 3.0 Audio Systems, with initial complete system submissions due by Jan. 12, 2015.

It appears that whatever the audio system ends up being in ATSC 3.0, it will be a complete solution from a single company as opposed to a system with technology sourced from many companies. Needless to say, we won’t see audio objects delivered via broadcast in the home for quite some time.

Immersive audio, however, has taken off in a huge way, especially in cinema with the release of films in Dolby Atmos and Auro 11.1 formats. With the inevitable Blu-ray and streaming releases of immersive films to consumers, we will undoubtedly see additional speakers, immersive sound bars and sound frames from a variety of manufacturers cluttering living rooms across the country in the very near future.

# 3: LOUDNESS MANAGEMENT FOR MOBILE, ONLINE DELIVERY—HALF CORRECT
Mobile and streaming is a bit of a conundrum since the devices used to access the content over the air and over the Internet can be the same, though different technologies in the device get used for each.

During a trip to South Korea last year I learned that essentially every mobile phone there comes with unlimited data; that watching television on phones, while riding the subway or driving a vehicle, is something everyone does; and that an awful lot of the phones have an antenna to receive over-the-air DMB television broadcasts.

Compare that to how people use their mobile phones to watch television in the United States, where the majority of viewing seems to be Internet streaming with very little obvious viewing of over-theair broadcasts (based on my observations from the daily commute).

With the big cellular providers making handsets with receivers available and accessory manufacturers providing plug-ins and add-ons for tablets and other devices, there’s no reason people can’t watch broadcast television while they’re on the go, but I still wonder how many people are actually doing so in the United States.

Of course, one big problem with television on the go, whether broadcast or streaming, is that external environmental noise means dynamic range of the audio must be kept to a minimum and loudness management is critical.

On Jan. 30, 2013, the ATSC released their recommended practice A/154:2013, which specifies –14 LKFS as the target loudness level for audio content. This means that a pretty serious loudness practice already exists for mobile television delivery. However, we still have nothing solid for streaming Internet delivery loudness that I’m aware of.

NPR conducted a study on this in 2013 and I’ve been taking some content measurements— both of which we’ll cover in another column—but the results leave me wondering whether this will be the next battleground of consumer audio complaints as viewing of streaming content increases.

THE MISSING PREDICTION
I’m still kicking myself for omitting audioover- IP and AES-67 adoption as an important technology for broadcast audio in 2014, possibly the most important one, in fact. I simply focused too closely on the other predictions and ran out of room and left it out even though I already had plans to begin implementing the technology myself.

Obviously AoIP took off last year with lots of AES-67 compatibility announcements, culminating with a very successful AES-sponsored plugfest in Munich.

After a bit of actual experimentation with AoIP products I found that they behaved pretty much as I expected with high-quality audio, but there were some discovery issues when connecting devices from different manufacturers together, even when using the same AoIP technology. Still, I have high hopes for AoIP and think adoption will continue to escalate this year.

As you can see from this analysis of my 2014 predictions, my crystal ball is on the fritz, so either take my predictions with a grain of salt or just wait awhile, because I have the feeling that all of them will eventually come to pass—my timing is just a bit off.

Jay Yeary is a broadcast television engineer specializing in audio. He can be contacted via TV Technology.

The idea of moving audio over an Ethernet cable may be a difficult concept for some to grasp, but audio over IP (AoIP) has matured to the point that it’s only a matter of time until it becomes standard in television facilities.

Speakers, microphones, mixing consoles, intercoms and other systems are all beginning to ship with the technology built-in but broadcasters working in facilities that are currently embedded SDI, discrete AES or MADI may have trouble figuring out the reasoning behind it.

Primary drivers include the ability to utilize existing network infrastructure to grow and upgrade facilities without adding significant cabling and the prospect of carrying hundreds of audio channels over a single cable. However, there are some caveats to making this work in a real facility. Though many systems are already in place and working well, these tend to be end-to-end solutions from one manufacturer.

At some point these systems will need to interface with systems from other manufacturers as facility upgrades are made. In this column we’ll look at the problems presented by interfacing these systems and see whether AES67 offers any help.

AOIP SOLUTIONS

The most popular AoIP solutions currently in use are provided by just a handful of companies: Dante from Audinate; Ravenna from ALC Networx; Telos’ LiveWire; and WheatNet from Wheatstone. Each one of these companies offers a competing and not wholly compatible version of the technology.

Companies numbering in the hundreds have signed on as technology partners and are releasing products that support one of the technologies, but not the others. This lack of compatibility was frustrating to those ready to begin implementing AoIP. It also seemed destined to fragment the industry and possibly even derail the technology.

Fortunately the Audio Engineering Society saw this train wreck coming and decided to do something about it. A working group called “X192,” headed by CobraNet Creator Kevin Gross, was established and within just a few years the AES67 interoperability standard was released.

All of the main solution manufacturers were represented in the group, along other audio professionals, and they worked together to come up with a single standard that all could comply with. It certainly helped that the working group decided from the outset that it would not invent new technology, but would utilize the mature standards already in place in the IT industry and determine which of those standards worked best for audio.

AES67 uses IEEE 1588-2008 for clock, DiffServ for Quality of Service (QoS), Real Time Protocol (RTP) for transport, and Session Initiation Protocol (SIP) for connection management. Specifications for the audio are 96 kHz, 48 kHz or 44.1 kHz linear PCM at 16 or 24-bit, carrying from one to eight channels.

Because AES67 is designed to work on Layer 3, solutions based on it should be able to cross subnets, allowing for the possibility of large audio networks. Exceptions are made throughout AES67 for Audio Video Bridging, another emerging technology designed to carry audio as well as video over IP. AVB has some additional overhead requirements intended to make it more robust, but covering the details and pros and cons of AVB are outside the scope of this column.

INTERCHANGEABLE DEVICES

Even though AES67 establishes an interoperability standard it doesn’t mean every AoIP device will necessarily work interchangeably with every other. Audio streams will work between devices and clocking should be solid, but the systems won’t necessarily know much about each other.

One piece absent from the AES standard is discovery—omitting it was necessary to complete the standard in a timely manner—and all of the current commercial products already have their own version. Dante devices know about other Dante devices; Ravenna and LiveWire devices know about their own systems, but they don’t necessarily know about competitors’ products.

Also, even though they were part of the working group and made no mention of patent concerns during the review period prior to publication of the standard, Audinate now states that portions of the standard infringe on patents they hold.

This patent claim has put a bit of a damper on enthusiasm for AES67, though Telos Systems has released a statement claiming there’s nothing to worry about as they’ve been using the technologies in AES67 in their products since 2003, several years prior to the creation of Dante.

Regardless, the prospect of paying a licensing fee or going to court will give any manufacturer reason for serious contemplation before jumping into the AoIP pool.

The good news is that placing AoIP devices on a typical network and having enough bandwidth for audio and other traffic isn’t a problem, especially as network speeds increase. The most difficult part of a successful AoIP implementation may actually be obtaining cooperation from the IT department.

There has been much discussion on the topic of whether television engineers must now become network engineers as well and this may depend in part on the relationship between engineering and IT. It is critical that these groups work hand in hand to gain mutual understanding of issues such as security restrictions, media prioritization and guaranteed network uptime.

If they can’t work collaboratively then it may be necessary to build a separate network for media, which eliminates all cost savings realized by moving media over existing network infrastructure. The role of television engineers has changed significantly over the past two decades anyway: first with the requirement to support consumer-grade systems for production; then with the move to servers in tapeless workflow; and now as media becomes IP-centric.

Even if every engineer on staff doesn’t need to be CCNA or CompTIA+ certified, insuring that some of them have a deeper knowledge of networks and IP technology is an excellent way to solve problems quickly and maintain system uptime.

AoIP is here and, with SMPTE 2022 being fleshed out, video over IP is on its heels. Successful implementation of IP media technology will depend on understanding its current limitations, planning in advance how best to implement it, and by preparing the technology teams that will have to make the implementation work.

Jay Yeary spends his days working as a broadcast engineer for a large U.S. media company. He can be reached through TV Technology or via Twitter at @TVTechJay.

NEW YORK—A brilliant decision in developing the recent audio-over-IP standard, AES67-2013, was basing it on existing protocols.

One of the goals for this “AES standard for audio applications of networks—High-performance streaming audio-over-IP interoperability” was to provide low latency (less than 10 milliseconds) between and among AES67 devices on a network. With that in mind, the developers of this standard chose IEEE 1588. The most recent version is from 2008, and the standard is currently being reviewed for possible revisions.

“IEEE 1588 is used for high-speed synchronization over the network. It was the only obvious choice for establishing a synchronization mechanism” said Greg Shay, a member of the AES task group that developed the standard.

Industrial applications such as automation, control and measurement employ IEEE 1588 where precision timing in the nanosecond range or less is required. IEEE 1588 doesn’t automatically dictate the accuracy of the clock—rather it allows implementation to be as tight as required.

IEEE 1588 differs from network time protocol (NTP) in that the latter was not designed to have nanoseconds of precision.

RELYING ON THE CLOCK
Timing in video or digital audio systems is not a new concept. A video system relies on a master sync generator that produces black burst that’s distributed and hardwired to every video and digital audio device in the system. For standalone digital audio systems, it’s a word clock generator that provides the reference. In each of these cases, a separate cable is generally used for the timing reference.

IEEE 1588 system timing also relies upon clocks, as might be expected, but the clocks work a bit differently. Every AES67 device that needs to communicate with each other (such as audio consoles, codecs, processors, interface boxes) is connected to a network via Ethernet switches. It’s important to note that the network we’re talking about for AES67 isn’t the public Internet, but rather a managed network like an enterprise LAN or WAN. And to achieve its low-latency potential, professional- grade (high performance) Ethernet switches are necessary. (More on switches in a bit.)

Each device connected to the network has its own clock. One clock that is used for reference is designated the “grandmaster.” IEEE 1588 provides a means for the network to automatically designate a clock as a grandmaster based on its stability, accuracy and quality, among other criteria. For example, a clock referenced to GPS would be a likely candidate for grandmaster status.

While the grandmaster reference can, in theory, be anywhere on a network, Shay said it’s best if it’s located near other devices on the network (such as those within a facility) to avoid long IP connections.

The grandmaster transmits over the network a small packet of data, the PTP message, with a time stamp of the current time. This multicasted message is received by all the other devices on the network, the “slaves,” which synchronize to the reference. Or thinking in video systems terms, the devices are effectively “gen-locked” to the reference.

Unlike in a video system, the IEEE 1588 timing reference doesn’t travel on separate cables. Rather it is transmitted on the same network as the digital audio packets. However the timing and audio packets are completely separate. When the PTP message (clock data) is received by a device on the network, it runs an algorithm to adjust its local clock to synchronize with the grandmaster clock.

When the grandmaster sends its PTP messages, it takes a finite amount of time to reach all the slave devices on the IP network. To provide greater timing accuracy, IEEE 1588 provides a means to measure the roundtrip time from grandmaster to slave and back to grandmaster, and to compensate for this offset.

BACK TO THE SWITCHES
In addition to this roundtrip delay, there are also delays through the Ethernet switches themselves as they buffer and transmit data packets. If a switch could provide a measurement of how long it takes a packet to get through it, that information could also be used to fine-tune timing. The 2008 revision of IEEE 1588 provides for what is called a “transparent clock” that does just that.

A switch with a transparent clock, “tries to correct the time stamp for the time packet,” Shay, who is also chief science officer for Telos Alliance, said. “This occurs in the switch itself and reduces the error at each stage of the process.”

A problem for an AES67 system design is that switches with transparent clocks aren’t that common, at least not right now. “There are some IEEE 1588-aware switches.” Shay said. “These switches are not yet ubiquitous, but they are becoming more available. [The system] works better with the special switch, but you don’t have to use them. There’s less error with an IEEE 1588 switch, but you can achieve a certain level of accuracy without [it].”

In addition to the types of clocks already mentioned, IEEE 1588 describes yet another type, a “boundary clock,” which slaves to a grandmaster and, acting like a sub-master, retransmits timing data to slave devices down the line.

Audio over IP is multichannel in the sense that a source connected in some way to the network can be made available to every other destination device. No more need for audio distribution amplifiers to send shared feeds to different studios.

Shay said that a 1 gigabit Ethernet connection can carry 250 stereo audio channels. Of course redundant cables would be good systems design.

“This is the point where MADI is way obsolete,” he said. “AoIP has many times more capacity than MADI with a smaller cable connection.”

What is AES67?

From the Audio Engineering Society’s Publication of the AES67 Standard:

“High-performance media networks support professional quality audio (16 bit, 44,1 kHz and higher) with low latencies (less than 10 milliseconds) compatible with live sound reinforcement. The level of network performance required to meet these requirements is available on local-area networks and is achievable on enterprise-scale networks.

A number of networked audio systems have been developed to support high-performance media networking but until now there were no recommendations for operating these systems in an interoperable manner. This standard provides comprehensive interoperability recommendations in the areas of synchronization, media clock identification, network transport, encoding and streaming, session description and connection management.”

For more information, visit www.aes.org.

Another plus for AoIP is that it can, through an IP network, tie together studios or facilities that are remotely separated, such as studios in two different cities, or remote trucks to studio, or even truck to truck or truck to announce booth. Not only outputs from one location could feed others, but sources could also be made accessible as well. But how would these systems be synced together?

Shay suggested that each location have a GPS receiver connected to the network to obtain a global time base. He noted that while there are GPS receivers with built-in IEEE 1588, they are not nearly as common as GPS receivers with NTP. So until GPS with IEEE 1588 becomes more available, one way around this situation is to sync an IEEE 1588 grandmaster to NTP that is synced to GPS.

Precision time synchronization as well as low packet size for the audio payload has allowed AES67 to achieve its target audio latency for AoIP.

Considering the potential of AES67 as a whole, “we are coming to a crossroads,” Shay said. “When the transformation is complete, there will be no more XLR devices.”

Thanks to Greg Shay who provided background information for this article.

Mary C. Gruszka is a systems design engineer, project manager, consultant and writer based in the New York metro area. She can be reached via TV Technology.

Audio system design has been an ever-evolving process. As new technologies emerge they add to and complement what’s come before, or replace existing structures.

Analog transitioned to digital. Single signal per cable wiring shifted to multiple multiplexed signals such as AES3 and MADI. Mixers with dedicated inputs and outputs have morphed into mixing control surfaces that act on sources wired to a central electronics hub. Distribution amplifiers are being replaced by Ethernet switches to allow multiple control surfaces and destinations access to any signals within a closed network.

The next step in this evolution looks to be audio-over-IP, or rather more of it. With the publication of AES67-2013, “AES standard for audio applications of networks— High-performance streaming audio- over-IP interoperability,” in September 2013, greater opportunities for integrating IP technology are forecast.

Such was the sentiment expressed at the DTV Audio Group Forum held in New York in December. The forum presented an overview of AoIP, how it compares to other interconnection technologies, and application potential.

“Looking forward, AES67 is enabling where the future is going,” said Greg Shay, chief science officer, Telos Alliance, and one of the DTV Audio Forum’s presenters. “It’s not just an interface technology, but how you interconnect and define a facility. We want the studio to fit into the whole world.”

While high-performance AoIP technology and equipment have been around for at least a decade, my impression is that these systems have been more prevalent in radio than TV installations, and as a way of distributing audio within closed systems.

COMPATIBLE COMMUNICATIONS
A stumbling block for more extensive applications was that systems made by different manufacturers weren’t compatible with each other. Similar, yes; IP-based, yes; but not close enough. AES67 should change that, and if the standard is followed, then different manufacturers’ AoIP gear should be able to communicate with each other and pass and interpret AoIP packets from one system to another, both inside a facility, and outside to wide area networks.

Andreas Hildebrand This interoperability with its potential for outside-world connectivity is the key to expanding AoIP opportunities for broadcast, TV, audio and video post and music recording facilities, TV trucks, stadiums and other venues. Facilities can be geographically apart, yet bound together virtually. Or be closer, such as a mobile production truck parked outside of a stadium.

AES67 was developed for what’s considered high-performance audio, that is, at least 16 bit/44.1 kHz full-bandwidth digital audio with a low latency, less than 10 msec. The standard covers synchronization, media clocks, transport, quality of service, encoding and streaming and session description.

“The interoperability of AES67 is based on 10 years of industry experience,” Shay said. For AES67, no new protocols were devised. It is based on existing protocols and standards from organizations such as AES and IEEE, and on the Open Systems Interconnect (OSI) model of network architecture using abstract or virtual layers.

The layer structure needs some explanation to understand how AES67 AoIP compares with Ethernet-based technologies. Andreas Hildebrand, senior product manager at ALC NetworX GmbH, provided a brief overview at the DTV Audio Forum.

Layer 1, the lowest layer, is the physical layer, which can be a copper or fiber connection over which data is transferred between a transmitting device and receiving device. (Radio-link connections are covered by this layer.)

Layer 2 is the data link layer, the layer used by Ethernet-based technologies like AVB (Audio Video Bridging) and TDM (time division multiplexing).

AES67 uses Layer 3 for AoIP. This is the network layer, with an IP-based suite of protocols for packet forwarding between networks (including the internet). According to the standard, Layer 3 “is responsible for packet forwarding and routing of variable-length data sequences from a source to a destination.”

AES67 also uses Layer 4, the transport layer, which, according to the standard, “provides end-to-end communications between devices on a network. The layer handles issues of packet loss and reordering and implements multiplexing so that a single network connection can serve multiple applications on the end station.” The standard calls for realtime transport protocol (RTP) for AoIP.

There are three other OSI Layers—5, 6 and 7—but they aren’t relevant here.

Each layer is “stacked” on top of the next lower layer, with data passing down in a specific way from one layer to the next lower one. But devices on a given layer can virtually communicate with each other.

As Hildebrand explained, Layer 1 systems tend to be proprietary, mostly based on fiber or copper connections, using point-to-point or chain topologies. Switches tend to be custom- built, devices tend to be fixed, with limited channel capacity and support for selected media formats. Because of their proprietary nature, these systems are typically based on a single manufacturer’s products, but for the same reason are generally quite rugged and have very low latency.

Layer 2 systems also tend to be proprietary. These are Ethernet-based, with channel capacity determined by the bandwidth of the Ethernet channel. Devices are connected in a local area network, but “you can’t cross out of the LAN,” Hildebrand said. AVB systems fall into this category. “You need to have an AVB switch,” Hildebrand said. “If you stay inside the AVB cloud, all data is preserved by built-in quality of service mechanisms. [But] none of the AVB streams can pass across a non-AVB bridge to another cloud.”

For Layer 3 systems, Hildebrand said that although there are proprietary systems, most are based on standardized Internet protocols supported by standard switches. This allows networks to connect to other networks. In this layer, “the size of the network is not limited,” Hildebrand said. It is “flexible, scalable, with a flexible choice of media format. Latency varies depending on the size of the network and the utlized payload format.”

As mentioned, AES67 was developed to have low latency, less than 10 msec. Clocking and synchronization, packet size and other encoding and streaming criteria all play a role. These will be discussed next time.

Mary C. Gruszka is a systems design engineer and consultant based in New York. She can be reached via TV Technology.

One day, soon perhaps, the miles of cabling required to shuttle audio and video from point to point will be relegated to the dustbin. The AES67-2013 standard for streaming audio has now been published, and the upcoming AES Convention (Thursday, Oct.17, through Sunday, Oct. 20, at the Javits Center in New York City) will have a number of seminars dealing with networked audio.

If you’re interested, check out the Networked Audio Track seminar (http://www.aes.org/events/135/networkaudio/) that Tim Shuttleworh, Engineering Manager at Renkus-Heinz, will be chairing. “Networking will influence every aspect of professional audio within the next several years, and it’s already well-entrenched in areas such as installed sound and live sound,” Shuttleworth says. “Networked audio is very rapidly integrating itself into the very fabric of pro audio, in a wide range of applications. As a result, learning as much as you can about networked audio is critical to furthering a career in any corner of the industry. This track was developed with that in mind, to offer a wide range of information to the widest audience possible.”